fix(core): do not unnecessarily defer offline transport send - #24027
Merged
Conversation
`makeOfflineTransport` awaited the `shouldSend` result unconditionally. The option type allows a plain boolean, and awaiting one still costs a microtask tick, so a synchronous callback pushed the call to `transport.send()` into the next turn. Only await when the callback returns a thenable. Hosts such as Douyin mini-games stop JS execution when the app goes to the background, so that one tick was enough to lose the event: the envelope had not reached the transport, and the offline store only gets written in the `catch` branch, which never runs when `shouldSend` returns true. Behavior is unchanged for callbacks that return a promise. fixes #24005 fixes JS-3560 Co-Authored-By: yaoxp <viq_xp@126.com>
Contributor
size-limit report 📦
|
RulaKhaled
approved these changes
Sep 4, 2026
Lms24
approved these changes
Sep 4, 2026
| const decision = options.shouldSend(envelope); | ||
| // avoid extra microtask tick, as some hosts stop JS execution | ||
| // when the app goes to the background. | ||
| const shouldSend = isThenable(decision) ? await decision : decision; |
Member
There was a problem hiding this comment.
m: I think we have a similar issue with shouldQueue/options.shouldStore below. might be worth checking and adjusting while we're at it.
Member
Author
There was a problem hiding this comment.
Good catch, yes, applied that as well.
I wonder if there's a way to make our linter catch this general pattern, where we unconditionally await something that could be a non-promise. 🤔 It could be annoying to be nagged to isThenable(x) everywhere, but I'm curious now how common this is. It's basically always going to be a correctness and/or performance improvement to avoid the await for sync values.
UPDATE: ok, threw a clanker at this question, and I'm now convinced it's not worth doing, so I'm ditching the idea.
- It's not something we can easily do with oxlint, or even scripting against the tsgo compiler we use, since none of the type checking is easily pluggable.
- eslint rules are syntax only, not pluggable type-aware rules.
- we CAN do it with a standalone script that uses the JS typescript lib, which I had it do, and it found 26 cases where we have a return value that's awaited, and might not contain a
thenfunction. However, apart from these two being fixed in this PR, the others are all build-time or startup paths where it doesn't matter as much. isThenable(x) ? await x : xeverywhere would increase bundle size for little gain, and it is uglier to human eyes.- We can just be mindful of this when operating in the
send()path, which we'll probably do just by copying the pattern that's fixed here anyway, so there's little added benefit.
isaacs
enabled auto-merge (squash)
September 4, 2026 15:46
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
makeOfflineTransportawaited theshouldSendresult unconditionally. The option type allows a plain boolean, and awaiting one still costs a microtask tick, so a synchronous callback pushed the call totransport.send()into the next turn.Only await when the callback returns a thenable. Hosts such as Douyin mini-games stop JS execution when the app goes to the background, so that one tick was enough to lose the event: the envelope had not reached the transport, and the offline store only gets written in the
catchbranch, which never runs whenshouldSendreturns true.The same treatment is applied to
options.shouldStore/shouldQueuemethod in the same file.Behavior is unchanged for callbacks that return a promise.
fixes #24005
fixes JS-3560