-
Notifications
You must be signed in to change notification settings - Fork 10
Description
Problem
rewindInstance and restartOrchestration in TaskHubGrpcClient (packages/durabletask-js/src/client/client.ts, lines 570–588 and 628–642) catch gRPC errors and rethrow new Error objects with user-friendly messages, but discard the original error. The { cause: e } option (available since ES2022, which this repo targets) is not used.
This means when users catch these errors, they cannot access the original gRPC ServiceError details — including gRPC metadata, status details, and the original stack trace — making it significantly harder to debug orchestration failures.
Example
try {
await client.rewindInstance(instanceId, "retry after fix");
} catch (e) {
// e.message is "An orchestration with the instanceId ... was not found."
// e.cause is undefined — the original gRPC ServiceError with metadata,
// status details, and stack trace is lost
}Additionally, rewindInstance uses inconsistent gRPC error detection (typeof e === "object" && "code" in e) compared to restartOrchestration which uses the more type-safe e instanceof Error && "code" in e pattern.
Root Cause
The catch blocks in both methods create new Error objects without passing { cause: e } as the second argument. The codebase already uses { cause: e } correctly in other locations:
packages/durabletask-js/src/worker/entity-executor.ts:102packages/durabletask-js/src/utils/pb-helper.util.ts:434
These two client methods were not updated to follow the same pattern.
Proposed Fix
- Add
{ cause: e }to all rethrown errors in bothrewindInstanceandrestartOrchestration - Standardize
rewindInstancegRPC error detection to useinstanceof Error(consistent withrestartOrchestration)
Impact
Severity: Medium — does not cause incorrect behavior, but makes debugging gRPC failures significantly harder for SDK users.
Affected scenarios: Any error handling code that catches errors from rewindInstance or restartOrchestration and inspects error.cause for diagnostic purposes.