[workflows-shared] Emulate deterministic-ID uniqueness in the local Workflows binding - #14847
Open
TheSaiEaranti wants to merge 2 commits into
Open
[workflows-shared] Emulate deterministic-ID uniqueness in the local Workflows binding#14847TheSaiEaranti wants to merge 2 commits into
TheSaiEaranti wants to merge 2 commits into
Conversation
…orkflows binding The local binding created duplicate executions for deterministic instance ids: create() never checked for an existing instance and createBatch() mapped every input through create(), so code relying on the documented idempotency contract appeared to work locally while double-executing workflow bodies. Match the documented production behavior: create() with an id that already exists throws and retains the existing instance, and createBatch() skips ids that already exist, or repeat within the batch, excluding them from the result and creating instances in batch order. Existence is decided by the engine Durable Object via a new hasInstance() method that reads INSTANCE_METADATA, which is written exactly once by the first init(), so the check is consistent across isolates rather than relying on binding-local state. Auto-generated ids skip the check. Fixes cloudflare#14836
🦋 Changeset detectedLatest commit: 30229c0 The changes in this PR will be included in the next version bump. This PR includes changesets to release 8 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 |
workers-devprod
requested review from
a team and
jamesopstad
and removed request for
a team
July 25, 2026 23:30
Contributor
|
Codeowners approval required for this PR:
Show detailed file reviewers
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
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
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.
Fixes #14836.
The local Workflows binding did not emulate the documented deterministic-ID uniqueness contract, in the dangerous direction: code relying on "duplicate create with the same ID is safely deduplicated" appeared to work locally while double-executing workflow bodies.
This PR matches the documented production behavior:
create({ id })with an ID that already exists throws (Workflow instance with id "<id>" already exists) and the existing instance is retained.createBatch()skips IDs that already exist — or that repeat within the batch — excluding them from the result, and creates instances in batch order.crypto.randomUUID()) IDs skip the existence check; their behavior is unchanged.How existence is decided: a new
Engine.hasInstance()RPC readsINSTANCE_METADATAfrom Durable Object storage, which is written exactly once by the firstinit()for the ID. Consulting the engine DO keeps the answer consistent across isolates rather than relying on binding-local state, and the DO's input gates order a sequential duplicatecreate()after the firstcreate()'sinit()dispatch, so the sequential case in the issue's repro is deterministic.init()itself is untouched — it is intentionally re-entrant (the engine calls it on restart/wake paths).One boundary note: two
create()calls for the same ID racing in the same tick (Promise.all) remain best-effort, since fully closing that window would require moving creation into a single engine RPC and changinginit()'s contract. The issue's repro (sequential awaited creates) is fully handled.Tests: four new cases in
binding.test.ts— duplicatecreate()throws;createBatch()excludes an existing ID (returns[], and[fresh]for a mixed batch); within-batch duplicates collapse to one; auto-generated IDs unaffected. Fullworkflows-sharedsuite: 153 passed.tscclean, oxfmt applied.