fix(core): don't assume a 64-character idempotency key is pre-hashed on reset - #4626
fix(core): don't assume a 64-character idempotency key is pre-hashed on reset#4626claude[bot] wants to merge 2 commits into
Conversation
…on reset `resetIdempotencyKey` treated any 64-character string as an already-computed hash and sent it to the API verbatim. That short-circuit ran before the scope logic, so a user key that is itself a 64-character digest had an explicitly passed `scope` silently discarded and was sent un-hashed, matching no run. A 64-character string is now only passed through when there is evidence it is already a hash: the idempotency key catalog recognises it (so it came from `idempotencyKeys.create()`), or no `scope` was passed and the length is the only signal available. An explicit `scope` is an explicit request to derive the hash, so it is always honoured. This keeps both existing behaviours intact: a key from `idempotencyKeys.create()` is still forwarded unchanged, and 64-character key material passed straight to `trigger()` and reset without a scope is still sent verbatim. `isIdempotencyKey` is deliberately untouched, since the trigger path is self-consistent and changing it would invalidate already-stored keys. Co-Authored-By: Claude <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: 6016987 The changes in this PR will be included in the next version bump. This PR includes changesets to release 27 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Co-Authored-By: Claude <noreply@anthropic.com>
@trigger.dev/build
trigger.dev
@trigger.dev/core
@trigger.dev/python
@trigger.dev/react-hooks
@trigger.dev/redis-worker
@trigger.dev/rsc
@trigger.dev/schema-to-json
@trigger.dev/sdk
commit: |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| // A 64-char key is only assumed pre-hashed if the catalog knows it, or there's no scope to hash with | ||
| if (typeof idempotencyKey === "string" && idempotencyKey.length === 64) { | ||
| return client.resetIdempotencyKey(taskIdentifier, idempotencyKey, requestOptions); | ||
| } | ||
| const isCreatedKey = getIdempotencyKeyOptions(idempotencyKey) !== undefined; | ||
|
|
||
| // Try to extract options from an IdempotencyKey created with idempotencyKeys.create() | ||
| const attachedOptions = | ||
| typeof idempotencyKey === "string" ? getIdempotencyKeyOptions(idempotencyKey) : undefined; | ||
| if (isCreatedKey || options?.scope === undefined) { | ||
| return client.resetIdempotencyKey(taskIdentifier, idempotencyKey, requestOptions); | ||
| } | ||
| } |
There was a problem hiding this comment.
🟡 Resetting a generated idempotency key stops working when the reset happens outside the run that created it and a scope is given
A key produced by the key-creation helper is now re-hashed instead of being sent as-is (generateIdempotencyKey at packages/core/src/v3/idempotencyKeys.ts:276) whenever the process that resets it no longer remembers the key and a scope was also passed, so the reset matches nothing and fails.
Impact: Users who reset a previously created key from another run, process, or backend while also passing a scope will find the reset silently does nothing.
Catalog-miss + explicit scope now falls through to hashing an already-hashed value
Before this change any 64-character string was forwarded verbatim, so a key from idempotencyKeys.create() always reset correctly regardless of scope and regardless of which process performed the reset. Now the pass-through at packages/core/src/v3/idempotencyKeys.ts:238-244 requires either a catalog hit or options.scope === undefined.
The catalog is in-process and is cleared at every run boundary by the workers (packages/cli-v3/src/entryPoints/managed-run-worker.ts:354, packages/cli-v3/src/entryPoints/dev-run-worker.ts:382). So for the documented flow "create the key in a task, reset it later" (docs/idempotency.mdx:388-402) combined with an explicit { scope: "global" } — e.g. resetting from backend code or from a later run on a warm worker — getIdempotencyKeyOptions() returns undefined, the guard fails, and the already-hashed 64-char digest is hashed a second time (plus scope suffix). The server stores the first digest, so the reset never matches. The new test at packages/core/src/v3/idempotencyKeys.test.ts:119-124 only passes because it does not reset the catalog between create and reset.
Prompt for agents
resetIdempotencyKey in packages/core/src/v3/idempotencyKeys.ts now only forwards a 64-character key verbatim when the in-process idempotency key catalog recognises it, or when no scope was passed. The catalog is process-local and is cleared at each run boundary by the CLI workers (managed-run-worker.ts / dev-run-worker.ts), so a key created with idempotencyKeys.create() and reset later from a different process or a different run — while also passing an explicit scope — is no longer recognised. It then falls through to generateIdempotencyKey and gets hashed a second time, producing a digest the server never stored, so the reset silently matches nothing (404). This is a regression from the previous length-based pass-through, which handled that case correctly. Consider a way to distinguish already-hashed keys from 64-char user material that does not rely on the process-local catalog (for example an explicit option such as `preHashed`/`raw`, or requiring the caller to opt in to hashing), or at minimum document/handle the created-key-plus-scope combination so it is not double hashed. Also reconcile with the docs in docs/idempotency.mdx which show resetting a created key and separately show passing an explicit scope.
Was this helpful? React with 👍 or 👎 to provide feedback.
| // A 64-char key is only assumed pre-hashed if the catalog knows it, or there's no scope to hash with | ||
| if (typeof idempotencyKey === "string" && idempotencyKey.length === 64) { | ||
| return client.resetIdempotencyKey(taskIdentifier, idempotencyKey, requestOptions); | ||
| } | ||
| const isCreatedKey = getIdempotencyKeyOptions(idempotencyKey) !== undefined; | ||
|
|
||
| // Try to extract options from an IdempotencyKey created with idempotencyKeys.create() | ||
| const attachedOptions = | ||
| typeof idempotencyKey === "string" ? getIdempotencyKeyOptions(idempotencyKey) : undefined; | ||
| if (isCreatedKey || options?.scope === undefined) { | ||
| return client.resetIdempotencyKey(taskIdentifier, idempotencyKey, requestOptions); | ||
| } | ||
| } |
There was a problem hiding this comment.
🔍 Trigger path and reset path can now disagree on 64-char material
isIdempotencyKey (packages/core/src/v3/idempotencyKeys.ts:52-61) still treats any 64-char string as pre-hashed on the trigger path, so trigger({ idempotencyKey: <64-char material> }) stores the raw value with no scope salt. The new reset logic, when given the same 64-char material plus { scope: "global" }, derives sha256(material) instead — which will not match what trigger stored. The PR's test at packages/core/src/v3/idempotencyKeys.test.ts:101-108 asserts this derived value equals what idempotencyKeys.create() produces, which is the correct target for keys created via create(), but users who passed 64-char material directly to trigger() and then pass a scope to reset() will now get a different (still non-matching) value than before. Worth confirming which of the two user flows the fix is intended to serve, since the length rule remains split across the two paths.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
Requested by Matt Aitken · Slack thread
idempotencyKeys.reset()now honours an explicitly passedscopeeven when the key material happens to be 64 characters long.Before:
resetIdempotencyKeytreated any 64-character string as an already-computed hash and sent it to the API verbatim. That short-circuit ran before the scope logic, so if your key material is itself a 64-character digest — a common pattern when you hash your own dedup identity — thescopeyou passed was silently discarded and the un-hashed material went on the wire. The server stores the hash, so the reset matched no run and returned 404 every single time. Key material of any other length worked fine, which made this look arbitrary.After: a 64-character string is only passed through when there is evidence it is already a hash. Otherwise an explicit
scopeis honoured and the hash is derived, at any key length.How
The pass-through now requires positive evidence rather than a length guess:
idempotencyKeys.create(), orscopewas passed, so there is nothing to derive a hash from and the length is the only available signal.An explicit
scopeis an explicit request to derive the hash, so it is never short-circuited past.Both existing behaviours are preserved:
idempotencyKeys.create()is still forwarded unchanged (catalog hit), including when ascopeis also passed — it is never hashed twice.trigger()is stored un-hashed, and resetting it with noscopestill sends it verbatim.isIdempotencyKeyis deliberately left alone: it applies the same length rule on the trigger path, but it is self-consistent there, and changing it would invalidate already-stored keys.The
attachedOptions?.key/attachedOptions?.scopefallbacks below the guard were unreachable — every catalog entry is a 64-character digest, so it always hit the short-circuit first — and re-deriving from them produces the identical hash anyway. They are removed rather than left as dead code.✅ Checklist
Testing
New tests in
packages/core/src/v3/idempotencyKeys.test.tsdrive the realresetIdempotencyKeyagainst a local HTTP server and assert on the exact value that reaches the wire — nothing is mocked. They cover:{ scope: "global" }resolves to the same valueidempotencyKeys.create()produces (fails without this change){ scope: "run", parentRunId }derives the run-salted hash (fails without this change)idempotencyKeys.create()is forwarded unchanged, with and without ascopescopeis still forwarded unchangedReverting only the source change turns the two new scope tests red and leaves the three compatibility tests green.
Changelog
idempotencyKeys.reset()now works when your idempotency key is itself 64 characters long. Previously any 64-character key was assumed to be already hashed, so passing one along with ascopesilently ignored the scope and the reset never found a matching run.Follow-ups (not in this PR)
docs/idempotency.mdxdescribes theidempotencyKeyparameter ofreset()as "the 64-character hash string" in one place while showing raw material plus{ scope: "global" }a few lines later. Worth reconciling.ctx.run.idempotencyKey, the run page and theidempotency_keyquery column all show the user-provided key. That is what leads people to send a value reset cannot match.