Problem
In InMemoryOrchestrationBackend.processCompleteOrchestrationAction(), when processing a CONTINUED_AS_NEW orchestration status, the customStatus field on the instance is not reset to undefined. Every other state field is properly reset:
instance.history = []
instance.input = newInput
instance.output = undefined
instance.failureDetails = undefined
instance.status = ORCHESTRATION_STATUS_PENDING
But instance.customStatus is omitted from this reset.
File: packages/durabletask-js/src/testing/in-memory-backend.ts, line ~481
Root Cause
The continue-as-new reset block in processCompleteOrchestrationAction() was written to reset the core state fields but customStatus was overlooked. Since completeOrchestration() only updates customStatus when the value is not undefined, a new iteration that doesn't call setCustomStatus() will inherit the stale value from the previous iteration.
Impact
Severity: Medium — This is a testing infrastructure bug.
When using the in-memory testing backend, orchestrations that use both setCustomStatus() and continueAsNew() will observe stale custom status values after the continue-as-new boundary. This can cause:
- Incorrect test assertions when checking custom status after continue-as-new
- False-positive test results where stale status values accidentally match expectations
- Confusing behavior when debugging custom status in test scenarios
The real gRPC sidecar creates a fresh execution for continue-as-new, so this bug only affects the in-memory test backend.
Proposed Fix
Add instance.customStatus = undefined; to the continue-as-new reset block in processCompleteOrchestrationAction(), alongside the existing resets for output, failureDetails, etc.
Problem
In
InMemoryOrchestrationBackend.processCompleteOrchestrationAction(), when processing aCONTINUED_AS_NEWorchestration status, thecustomStatusfield on the instance is not reset toundefined. Every other state field is properly reset:instance.history = []instance.input = newInputinstance.output = undefinedinstance.failureDetails = undefinedinstance.status = ORCHESTRATION_STATUS_PENDINGBut
instance.customStatusis omitted from this reset.File:
packages/durabletask-js/src/testing/in-memory-backend.ts, line ~481Root Cause
The continue-as-new reset block in
processCompleteOrchestrationAction()was written to reset the core state fields butcustomStatuswas overlooked. SincecompleteOrchestration()only updatescustomStatuswhen the value is notundefined, a new iteration that doesn't callsetCustomStatus()will inherit the stale value from the previous iteration.Impact
Severity: Medium — This is a testing infrastructure bug.
When using the in-memory testing backend, orchestrations that use both
setCustomStatus()andcontinueAsNew()will observe stale custom status values after the continue-as-new boundary. This can cause:The real gRPC sidecar creates a fresh execution for continue-as-new, so this bug only affects the in-memory test backend.
Proposed Fix
Add
instance.customStatus = undefined;to the continue-as-new reset block inprocessCompleteOrchestrationAction(), alongside the existing resets foroutput,failureDetails, etc.