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

Server crashes on every calls when extension returns a promise #2038

Closed
nick-keller opened this issue Nov 28, 2018 · 7 comments
Closed

Server crashes on every calls when extension returns a promise #2038

nick-keller opened this issue Nov 28, 2018 · 7 comments

Comments

@nick-keller
Copy link

Intended outcome

Returning a promise in the method willSendResponse of an extension should be supported

Actual outcome

If the method willSendResponse returns a promise or is async the server crashes on every calls and the client receives the errors: [{"message": "Cannot read property 'errors' of undefined"}]

How to reproduce the issue

Create a simple logging extension for an Apollo server 2:

const apolloServer = new ApolloServer({
  //...
  extensions: [ () => new Logger(), ],
})

And the logger:

export class Logger {
  async willSendResponse() {
    //...
  }
}

I'm assuming this is unintended and this sould be an easy fix ;)

@nick-keller
Copy link
Author

Am I the only one in need of async actions in extensions?

@pierreericgarcia
Copy link

✋🏻In need too

@strctr
Copy link

strctr commented Mar 14, 2019

Yes, facing the same issue.

@strctr
Copy link

strctr commented Mar 15, 2019

Actually this bug prevents us to use Apollo Server. We have the following case: for some queries we want to have export files that contains the same data as result of the query. To send export file id we use extensions field in the response. But to create and publish file we need to do async actions during the construction of the extensions field. But making willSendResponse as async crashes the server.

I spent entire day to find workaround but failed. Any suggestions?

@nick-keller what about adding label tag: graphql-extensions?

@ruizmarc
Copy link

✋🏻 it would be very useful for us also! We have a use case in which we need to do some async post procesing in willSendResponse. Is there any workaround?

@paumartin
Copy link

✋🏻 Same here

@abernix
Copy link
Member

abernix commented May 24, 2019

This is supported by the new request pipeline plugin API. The graphql-extensions API is not being actively maintained anymore and is being replaced by in favor of the new request pipeline which first surfaced in #1795 and aims to cover a wider range of functionality than graphql-extensions which was never documented nor intended to be public API.

The new API (which can be utilized by providing plugins to the ApolloServer constructor) supports more integration points (e.g. server startup, where as extensions were only ever per-request), and in the future will support schema generation hooks and more, all with a strongly-typed API.

While the new API is still growing, the documentation is taking form in #2008 (there's a preview link on that PR so you can view them in a more glorious form than the raw markdown) and building out the API further is on our roadmap for Apollo Server 3.0, as noted in #2360.

I'll close this, but if you take a look at the documentation and the source types in apollo-server-plugin-base (used by package authors to implement plugins, for example), you should be able to get an idea, and we intend on supporting this longer-term.

In the case of willSendResponse, you'll find it does support returning a Promise and can be used today:

willSendResponse?(
requestContext: WithRequired<
GraphQLRequestContext<TContext>,
'metrics' | 'response'
>,
): ValueOrPromise<void>;

I didn't finish writing the text blurb for willSendResponse in those docs previews, but I think you'll get the idea. Let me know if you have any questions.

@abernix abernix closed this as completed May 24, 2019
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 21, 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

No branches or pull requests

6 participants