[copilot-finds] Bug: TestOrchestrationWorker processing loop crashes when completeOrchestration fails in error handler #174
Description
Problem
InMemoryOrchestrationBackend.completeOrchestration() throws an Error when the target instance does not exist (e.g., after backend.reset() or purgeOrchestration()), but the sibling method completeActivity() silently returns for the same scenario. This inconsistency causes TestOrchestrationWorker.processOrchestration() to crash when its catch block calls completeOrchestration on a purged instance.
File: packages/durabletask-js/src/testing/in-memory-backend.ts, line 257
File: packages/durabletask-js/src/testing/test-worker.ts, lines 155-158
Root Cause
In in-memory-backend.ts:
completeOrchestration()(line 257):throw new Error(...)when instance not foundcompleteActivity()(line 311): silently returns when instance not found
In test-worker.ts, processOrchestration() has a catch block that calls completeOrchestration to report failures. If the instance was deleted between scheduling and completion (e.g., via reset()), the throw propagates out of the catch block, crashing runProcessingLoop(). The worker silently stops processing all subsequent work items.
Proposed Fix
- Root cause: Change
completeOrchestrationto return silently when the instance is not found, consistent withcompleteActivity. - Defense-in-depth: Wrap the catch block's
completeOrchestrationcall in a nested try-catch so the worker survives even ifcompleteOrchestrationthrows for other reasons.
Impact
- Severity: Medium — affects testing infrastructure only (not production runtime)
- Scenarios affected: Any test that calls
backend.reset()orpurgeOrchestration()while orchestrations are in flight. The worker stops processing silently, causing subsequent test assertions to hang or time out with confusing errors.