Skip to content

test: separate a retried trigger from a new trigger with the same run id - #219

Merged
CahidArda merged 1 commit into
mainfrom
test/trigger-retry-vs-new-trigger
Oct 1, 2026
Merged

CahidArda merged 1 commit into
mainfrom
test/trigger-retry-vs-new-trigger

Conversation

@CahidArda

Copy link
Copy Markdown
Collaborator

Why

Workflow Requests > should omit some errors > should omit the error if the workflow is created with the same id fails when the SDK tests run against a QStash built from upstash/qstash-server#1129.

That's expected. Since #214, a trigger carries Upstash-Workflow-CreatedAt, and #1129 adds it to the deduplication of workflow requests. So the trigger time now decides whether a trigger for a taken run id counts as a duplicate. The old test built two contexts with workflowRunCreatedAt: 0, so triggerFirstInvocation gave each one its own Date.now(). Against #1129, the second trigger is therefore a new trigger, not a retry. It isn't deduplicated; QStash rejects it with 400 a workflow already exists, can not initialize a new one with same id.

Change

The test is split into the two cases it now covers, in src/workflow-requests.test.ts:

  • should omit the error if the same trigger is retried: both triggers carry the same trigger time, as a retry of the same request does. The second one is deduplicated and returns "workflow-run-already-exists" with the warning, as before. The server PR tests the same thing ("A retry of the same trigger is deduplicated").
  • should return an error if a new trigger uses the id of a run in progress: the second trigger has a different trigger time, so it's a new trigger. It returns an error containing "a workflow already exists".

Cleanup now uses workflowClient.cancel([workflowRunId]), like the other tests in this block, instead of triggerWorkflowDelete. The contexts hold the trigger time, not the run's actual creation time, and since #1129 QStash ignores a delete whose creation time doesn't match.

Notes

  • These are live tests (they need QSTASH_TOKEN). The second test only passes against a QStash with #1129. Production QStash without it still deduplicates the second trigger, so it would return "workflow-run-already-exists" instead of an error. It'll fail in this repo's CI until #1129 is deployed.
  • I haven't run them against a live QStash. tsc, eslint and prettier --check pass. The error message checked is the one a local QStash built from #1129 returned for a second client.trigger while the run was in progress.

🤖 Generated with Claude Code

https://claude.ai/code/session_017dm7F4hg2khgYDqBwP9nx5

With Upstash-Workflow-CreatedAt in the deduplication of workflow requests
(upstash/qstash-server#1129), the trigger time decides whether a trigger
with a taken run id is a duplicate. The old test triggered twice with a
fresh trigger time each time, so against a server with #1129 the second
trigger is a new trigger, not a retry, and is rejected instead of being
deduplicated.

- A retried trigger sends the same trigger time, and is still deduplicated
  with "workflow-run-already-exists" and a warning.
- A new trigger for the id of a run in progress returns an error, because
  the run id is taken.

The runs are cancelled by id: the contexts hold the trigger time, not the
creation time of the run, and a delete with a different creation time is
ignored.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017dm7F4hg2khgYDqBwP9nx5
@CahidArda
CahidArda merged commit e4bac2b into main Oct 1, 2026
21 of 22 checks passed
@CahidArda
CahidArda deleted the test/trigger-retry-vs-new-trigger branch October 1, 2026 13:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant