🤖 tests: stabilize WorkflowService background interrupts

[ThomasK33]

Summary

Stabilizes WorkflowService unit coverage by removing a race in the foreground run-created callback test and treating user-interrupted background workflow exits as expected cancellations rather than background failures.

Background

Recent unit CI runs showed WorkflowService > notifies foreground run creation before the first workflow step blocks intermittently receiving both run-created and agent-started before the polling assertion ran. The service already awaited onRunCreated; the test was racing the runner after a synchronous callback returned.

The same CI window also showed noisy expected background-interrupt stack traces immediately before workflow tests continued. User interruptions should not be logged as background failures, but terminal callbacks that explicitly request interrupted notifications should still be delivered.

Implementation

• Gates the onRunCreated callback in the flaky test so the assertion checks the intended service ordering deterministically.
• Tracks in-progress interrupt status writes so background run cleanup waits for the durable interrupted status before deciding whether to log a failure.
• Adds coverage that interrupted background runs can still notify terminal observers without emitting console.error noise.

Validation

• bun test --max-concurrency=1 --coverage --coverage-reporter=lcov src/node/services/workflows/WorkflowService.test.ts
• Stress-ran the foreground run-created test 100 times locally before final validation.
• MUX_ESLINT_CONCURRENCY=1 make static-check

Risks

Low. The production change is scoped to WorkflowService background failure reporting after an explicit interrupt. Non-interrupted background failures still log and notify as before.

---

Generated with mux • Model: openai:gpt-5.5 • Thinking: xhigh • Cost: $32.88

[ThomasK33]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Swish!

Reviewed commit: 8f83304204

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".