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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Promises getting rejected with non-Error objects #531

Closed
gjbadros opened this issue Jan 20, 2024 · 2 comments
Closed

Promises getting rejected with non-Error objects #531

gjbadros opened this issue Jan 20, 2024 · 2 comments
Labels
enhancement New feature or request released Has been released and published

Comments

@gjbadros
Copy link

Hi! 馃憢

Firstly, thanks for your work on this project! 馃檪

Today I used patch-package to patch graphql-ws@5.14.3 for the project I'm working on.

Promises are getting rejected with non-Error objects, which cause bluebirdjs promise warnings/errors and is generally a bad practice. This is a minimal fix -- probably better to have a graphql-ws specific Error subclass, etc.

Here is the diff that solved my problem:

diff --git a/node_modules/graphql-ws/umd/graphql-ws.js b/node_modules/graphql-ws/umd/graphql-ws.js
index 3150aa0..38b2615 100644
--- a/node_modules/graphql-ws/umd/graphql-ws.js
+++ b/node_modules/graphql-ws/umd/graphql-ws.js
@@ -400,8 +400,9 @@
                     connecting = undefined;
                     clearTimeout(connectionAckTimeout);
                     clearTimeout(queuedPing);
-                    denied(errOrEvent);
-                    if (isLikeCloseEvent(errOrEvent) && errOrEvent.code === 4499) {
+                    const ilce = isLikeCloseEvent(errOrEvent)
+                    denied(new Error('graphql-ws: errorOrClosed', { ...errOrEvent, ilce }));
+                    if (ilce && errOrEvent.code === 4499) {
                         socket.close(4499, 'Terminated'); // close event is artificial and emitted manually, see `Client.terminate()` below
                         socket.onerror = null;
                         socket.onclose = null;
@@ -477,7 +478,8 @@
                         retries = 0; // reset the retries on connect
                         connected([
                             socket,
-                            new Promise((_, reject) => errorOrClosed(reject)),
+                            // new Promise((_, reject) => errorOrClosed(reject)),
+                            new Promise((_, reject) => errorOrClosed(() => reject(new Error('graphql-ws: Socket closed')))),
                         ]);
                     }
                     catch (err) {
@@ -738,11 +740,11 @@
             terminate() {
                 if (connecting) {
                     // only if there is a connection
-                    emitter.emit('closed', {
+                    emitter.emit('closed', new Error('graphql-ws: Terminated', {
                         code: 4499,
                         reason: 'Terminated',
                         wasClean: false,
-                    });
+                    }));
                 }
             },
         };

This issue body was partially generated by patch-package.

@enisdenjo
Copy link
Owner

Hey hey, this would make sense! I'd just prefer to have a concrete error class instead of relying on the message. Let's go with class TerminatedError extends Error.

Would you like to open a PR for this? Would be greatly appreciated. :D

@enisdenjo enisdenjo added the enhancement New feature or request label Jan 26, 2024
enisdenjo pushed a commit that referenced this issue Feb 12, 2024
# [5.15.0](v5.14.3...v5.15.0) (2024-02-12)

### Bug Fixes

* **client:** Use `TerminatedCloseEvent` class extending an `Error` for rejecting promises when terminating ([74b4ceb](74b4ceb)), closes [#531](#531)
* **server:** Dispose of subscriptions on close even if added late to the subscriptions list ([#534](#534)) ([e45d6b1](e45d6b1)), closes [#532](#532)

### Features

* **server:** Add is retry flag to connect events ([#507](#507)) ([9ad853f](9ad853f))
@enisdenjo
Copy link
Owner

馃帀 This issue has been resolved in version 5.15.0 馃帀

The release is available on:

Your semantic-release bot 馃摝馃殌

@enisdenjo enisdenjo added the released Has been released and published label Feb 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request released Has been released and published
Projects
None yet
Development

No branches or pull requests

2 participants