Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Misleading error if you set APOLLO_KEY to something that is not a service token #4640

Closed
glasser opened this issue Oct 9, 2020 · 0 comments · Fixed by #5241
Closed

Misleading error if you set APOLLO_KEY to something that is not a service token #4640

glasser opened this issue Oct 9, 2020 · 0 comments · Fixed by #5241

Comments

@glasser
Copy link
Member

glasser commented Oct 9, 2020

If you set APOLLO_KEY to something that does not start with service: (and don't explicitly set APOLLO_GRAPH_ID or apollo: {graphId}), then the usage reporting plugin will be installed by default, but it will fail with the misleading error

You've enabled usage reporting via ApolloServerPluginUsageReporting, but you also need to provide your Apollo API key, via the APOLLO_KEY environment variable or via `new ApolloServer({apollo: {key})'

The fix is twofold:

  • Make the error be clearer if the problem is specifically the lack of graph ID
  • Don't auto-load the plugin unless you have a graph ID

That said, usage reporting doesn't actually work for anything other than graph (service) tokens (ie, user tokens are not supported for usage reporting, though they are for schema reporting), so if you're not setting a service token it's not going to work.

glasser added a commit that referenced this issue May 26, 2021
Apollo Server shouldn't need to have deep knowledge of Apollo Studio's
data model. "ID and variant" are overly precise. This PR moves us
towards a world where Apollo Server only needs to be aware of the "graph
ref", a string like `id@variant` (but which might end up with other
spellings later).

We intend to remove the API key parser in Apollo Server 3 and stop
providing `graphId`/`graphVariant` to plugins and the gateway, but these
remain for now.

This PR:
- Allows you to specify the graph ref via `APOLLO_GRAPH_REF` or `apollo:
  {graphRef}`. It is an error to also specify ID or variant if you
  specify the ref.
- Makes `graphRef` available to plugins and the gateway alongside
  `graphId` and `graphRef`.
- If you specify an API key but it does not start with `service:` and
  you do not specify graph ref or graph ID, it throws an error. This
  fixes #4640. Note that while there are other legal Apollo key formats,
  Apollo Server only currently works with `service:*` keys.
- Switches usage reporting and schema reporting to use new protocols
  that specify the graph ref instead of the variant, and to print Studio
  URLs that use the graph ref instead of the ID and variant separately.
  (The old protocols didn't specify the ID because it was implied by the
  API key.)
- The schema reporter previously used Apollo Codegen without any
  documentation of how it worked. Set up graphql-code-generator instead
  and add an npm script to regenerate the types.

Part of #5157.
glasser added a commit that referenced this issue May 26, 2021
Apollo Server shouldn't need to have deep knowledge of Apollo Studio's
data model. "ID and variant" are overly precise. This PR moves us
towards a world where Apollo Server only needs to be aware of the "graph
ref", a string like `id@variant` (but which might end up with other
spellings later).

We intend to remove the API key parser in Apollo Server 3 and stop
providing `graphId`/`graphVariant` to plugins and the gateway, but these
remain for now.

This PR:
- Allows you to specify the graph ref via `APOLLO_GRAPH_REF` or `apollo:
  {graphRef}`. It is an error to also specify ID or variant if you
  specify the ref.
- Makes `graphRef` available to plugins and the gateway alongside
  `graphId` and `graphRef`.
- If you specify an API key but it does not start with `service:` and
  you do not specify graph ref or graph ID, it throws an error. This
  fixes #4640. Note that while there are other legal Apollo key formats,
  Apollo Server only currently works with `service:*` keys.
- If you specify an API key but don't specify a graph ref or ID, prints a deprecation
  warning telling you to set a graph ref.
- Switches usage reporting and schema reporting to use new protocols
  that specify the graph ref instead of the variant, and to print Studio
  URLs that use the graph ref instead of the ID and variant separately.
  (The old protocols didn't specify the ID because it was implied by the
  API key.)
- The schema reporter previously used Apollo Codegen without any
  documentation of how it worked. Set up graphql-code-generator instead
  and add an npm script to regenerate the types.

Part of #5157.
glasser added a commit that referenced this issue May 26, 2021
Apollo Server shouldn't need to have deep knowledge of Apollo Studio's
data model. "ID and variant" are overly precise. This PR moves us
towards a world where Apollo Server only needs to be aware of the "graph
ref", a string like `id@variant` (but which might end up with other
spellings later).

We intend to remove the API key parser in Apollo Server 3 and stop
providing `graphId`/`graphVariant` to plugins and the gateway, but these
remain for now.

This PR:
- Allows you to specify the graph ref via `APOLLO_GRAPH_REF` or `apollo:
  {graphRef}`. It is an error to also specify ID or variant if you
  specify the ref.
- Makes `graphRef` available to plugins and the gateway alongside
  `graphId` and `graphRef`.
- If you specify an API key but it does not start with `service:` and
  you do not specify graph ref or graph ID, it throws an error. This
  fixes #4640. Note that while there are other legal Apollo key formats,
  Apollo Server only currently works with `service:*` keys.
- If you specify an API key but don't specify a graph ref or ID, prints a deprecation
  warning telling you to set a graph ref.
- Switches usage reporting and schema reporting to use new protocols
  that specify the graph ref instead of the variant, and to print Studio
  URLs that use the graph ref instead of the ID and variant separately.
  (The old protocols didn't specify the ID because it was implied by the
  API key.)
- The schema reporter previously used Apollo Codegen without any
  documentation of how it worked. Set up graphql-code-generator instead
  and add an npm script to regenerate the types.

Part of #5157.
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant