Skip to content

feat(runner): key a runner run to its flow with --flow-id - #1628

Draft
Huishi (huishi329) wants to merge 4 commits into
mainfrom
huishi/runner-run-flow-id
Draft

Huishi (huishi329) wants to merge 4 commits into
mainfrom
huishi/runner-run-flow-id

Conversation

@huishi329

@huishi329 Huishi (huishi329) commented Sep 22, 2026 •

Copy link
Copy Markdown

Relates to qawolf/platform#33638 and Linear GRI-426.

Overview of Changes

Flows run on an interactive runner never received QAWOLF_WORKFLOW_ID, so a flow that keys its fixtures and cleanup on that id saw undefined. qawolf runner run now takes --flow-id, the flow the run is for, and the platform stamps it onto the run as QAWOLF_WORKFLOW_ID, like a platform run of that flow gets. The runner SDK's run verb takes the same flowId. Runs that name no flow are unchanged, and the CLI's own QAWOLF_WORKFLOW_ID is deliberately not read: only an AI Job's pod has one, and it names the pod's flow, not every flow run from there.

The bump to @qawolf/api-contracts 0.64.0 also brings runner.record and runner.recordings, added to the hand-written runner skip list so the generator does not mint them.

Blocked on publishing. 0.64.0 comes from qawolf/platform#33638 and is not on npm yet, so bun.lock is untouched. Once it is published: bun install, commit the lockfile, and CI can run. Verified locally against the platform branch's built 0.64.0.

Testing

bun run typecheck
bun run lint
bun run format:check
bun run knip
bun run test

All pass locally: 2613 tests, including runFlow.flowId.test.ts (flag sent, trimmed, absent, ambient variable ignored, blank flag refused) and the refreshed runner run --help snapshot.

Checklist

  • Changes follow the code style of this project
  • Self-review completed
  • Tests added/updated (or not applicable)
  • No breaking changes (or described below)

🤖 Generated with Claude Code

A run on an interactive runner never saw QAWOLF_WORKFLOW_ID, so a flow that
names and cleans up fixtures by it read undefined and Tester took the id for
unavailable. `qawolf runner run --flow-id` names the flow, falling back to
QAWOLF_WORKFLOW_ID from the shell, which the pod an AI Job runs on exports;
the platform stamps it onto the run as QAWOLF_WORKFLOW_ID. The runner SDK's
run verb takes the same flowId.

Takes @qawolf/api-contracts 0.64.0, which carries the field. That version
also adds runner.record and runner.recordings, listed with the rest of the
hand-written runner group so the generator does not mint them.
@coderabbitai

coderabbitai Bot commented Sep 22, 2026

Copy link
Copy Markdown

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

  • Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

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

The old wording said the run falls back to the variable, which reads as the
run reading the id it is about to be given. The CLI reads it, from its own
shell. Show the fixture-name convention the flag exists for instead of
naming it in the abstract.
The fallback read QAWOLF_WORKFLOW_ID from the CLI's own environment. Only an
AI Job's pod holds it, and there it is the id of that pod's own flow, not of
whatever flow the run is for. An agent on such a pod routinely runs sibling
flows, so the fallback would key those runs to the wrong flow and strand
their fixtures in another flow's namespace.

The flag is now the only source. A test pins that an ambient
QAWOLF_WORKFLOW_ID is ignored, so the fallback is not reintroduced.
Same facts in fewer words across the help text, changeset, skill, reference
and the helper's comment.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant