[dylan-conway]

What does this PR do?

Fixes the flaky "should return the same result as singing synchronously" in test/js/third_party/jsonwebtoken/async_sign.test.js. It timed out and passed on a retry in builds 127615 (Alpine 3.23 x64), 127674 (Debian 13 x64 ASAN), 127693 (Windows 2019 x64), 127852 (Debian 13 x64) and 127926 (Ubuntu 25.04 aarch64):

✗ signing a token asynchronously > when signing a token > should return the same result as singing synchronously [90000.00ms]
  ^ this test timed out after 90000ms, before its done callback was called.
15 pass
1 skip
1 fail
27 expect() calls

A run that passes also has 27 expect() calls, so in those builds the callback did run, and all three of its expects with it.

The test signs { foo: "bar" } asynchronously and, in the callback, once more synchronously, and expects the same token. jwt.sign adds iat, the current time in seconds, to a payload that has none. If a second begins between the two calls, the tokens differ and expect(asyncToken).toEqual(syncToken) throws. That is inside the try of jws's SignStream.prototype.sign, whose catch emits 'error'. The listener for that is the same callback wrapped in lodash.once, which has been called already. So nothing is reported, done is never called, and the test waits for its timeout.

The payload now has an iat, so both calls sign the same thing whenever they run.

How did you verify your code works?

Linux x64, with binaries CI built from main's code.

With a preload that makes every Date.now() one second later than the one before, main's file fails as in CI (that test alone, 15 pass, 1 skip, 1 fail, 27 expect() calls), and with this PR the file passes (16 pass, 1 skip).

With the real clock, that test alone, 8 runs at a time:

	main	this PR
release	25 of 4000 fail	0 of 8000
ASAN, CI's settings	16 of 600 fail	0 of 1200

With a preload that only records the two timestamps, in 4000 runs of main's file the 14 runs where they differ are the 14 that fail.

The test still checks what it did: with the asynchronous path made to sign another payload (a preload that patches jws.createSign), and with a process.nextTick that never runs its callbacks, it fails.

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 19 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used all 10 included reviews currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: Repository: oven-sh/bun/.coderabbit.yaml
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 998bb43c-9f93-4d1c-9b5c-2cac9073fd6d

📥 Commits

Reviewing files that changed from the base of the PR and between d0831bc and 5c8f0f7.

📒 Files selected for processing: 1

• test/js/third_party/jsonwebtoken/async_sign.test.js

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

^{Updated 9:08 PM PT - Oct 17th, 2026}

@dylan-conway, your commit 5c8f0f7 is building: #128009

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

LGTM — pinning iat removes the only time-dependent input to the two sign() calls, and the assertion still compares the async and sync tokens as before. I also checked the other jsonwebtoken tests for a second sign-vs-sign comparison that could race the same way; this is the only one.

Extended reasoning...

The change touches one vendored third-party test file, test/js/third_party/jsonwebtoken/async_sign.test.js, replacing two inline payloads with a shared payload that carries a fixed iat claim (+4/-2). No runtime or native code and no security-sensitive surface is involved. jsonwebtoken honors a caller-supplied iat (it only stamps the current second when the payload has none) and copies the payload unless mutatePayload is set, so sharing the object between the async and sync calls is safe. The original property (async and sync sign agree) is still asserted, and the one inline finding is a pre-existing hang-on-failure nit in the done-callback style shared by the whole vendored file, not something this PR introduces.

[dylan-conway]

Folded into #45873.