ref: Avoid some usage of SyncPromise where not needed
#17641
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
size-limit report 📦
|
node-overhead report 🧳Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.
|
mydea
force-pushed
the
fn/avoid-sync-promise
branch
from
9038bfe to
77dd72e
Compare
mydea
commented
Sep 15, 2025
mydea
force-pushed
the
fn/avoid-sync-promise
branch
2 times, most recently
from
241d7cf to
61a0aa7
Compare
This was referenced Sep 16, 2025
mydea
added a commit
that referenced
this pull request
Sep 16, 2025
This changes our fetch transport a bit, making use of async functions and slightly adjusting error handling: 1. Technically there was a bug if fetch is not available, as we would keep increasing the `pendingBodySize`/`pendingCount` and never decrease it. 2. We had some dedicated error messages for edge cases that are IMHO not necessary - we can safe a few bytes by just using default error messages there. 3. No need to use sync promise here, all of this is async anyhow. Extracted this out of #17641
mydea
added a commit
that referenced
this pull request
Sep 16, 2025
I noticed that we actually handled errors in `sendEnvelope` incorrectly - we would resolve this function with the rejection reason, if sending fails. this does not match the type of `TransportMakeRequestResponse`, you could actually get something like this out (and the tests actually incorrectly tested this): ```js // transport.send() rejects with "fetch does not exist" const res = await client.sendEnvelope(envelope); // res --> "fetch does not exist" (string) ``` This PR fixes this to instead resolve with an empty object (which matches the expected return type). Extracted this out of #17641 because it is actually a bug/fix.
mydea
force-pushed
the
fn/avoid-sync-promise
branch
2 times, most recently
from
59eeb61 to
b6c7507
Compare
We make quite heavy use of it in event processing, not touching this for now, but in other places it should not be needed IMHO. fix transport using async refactor some more sync promise stuff fix node client fix some flushing stuff fix check oops small fixees fix tests fix lint fix to promise like small ref avoid special casing of no fetch implementation fetch stuff
mydea
force-pushed
the
fn/avoid-sync-promise
branch
from
b6c7507 to
3bc8532
Compare
Lms24
approved these changes
Sep 17, 2025
Comment on lines
+319
to
+320
| // @ts-expect-error - PromiseLike is a subset of Promise | ||
| public async flush(timeout?: number): PromiseLike<boolean> { |
There was a problem hiding this comment.
So for a moment, I thought the async signature change would still be breaking for anyone currently extending Client and overriding this method (as in, them not having the async declaration). But it seems like this is fine (at least with the TS settings in our repo) and TS is smart enough to handle it. Just wanted to leave this thought here in case we can think of a TS setting or a scenario where this might be problematic.
Co-authored-by: Lukas Stracke <[email protected]>
This was referenced Sep 29, 2025
This was referenced Oct 7, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We make quite heavy use of it in event processing, not touching this for now, but in other places it should not be needed IMHO. These are all places that will never be sync generally speaking so it is fine to make them "proper" async.
Somewhat related to #17634