Problem
The _executeOrchestrator(), _executeActivity(), and _executeEntity() wrapper methods in task-hub-grpc-worker.ts (lines 612-622, 800-810, 882-893) create fire-and-forget promises tracked in _pendingWorkItems. These promises only have .finally() for cleanup but no .catch() handler.
The corresponding internal methods (_executeOrchestratorInternal, _executeActivityInternal, _executeEntityInternal) throw errors before their inner try/catch blocks when validation fails (e.g., missing instanceId). These early throws produce unhandled promise rejections.
Root Cause
In JavaScript, .finally() does not mark a rejection as handled — only .catch() does. So when:
_executeOrchestratorInternal throws at line 635 (missing instanceId)_executeActivityInternal throws at line 823 (missing orchestration instance)_executeEntityInternal throws at line 916 (missing instanceId)
...the rejection propagates as unhandled.
Impact
Severity: High. In Node.js 22+ (the minimum required version for this SDK), unhandled promise rejections terminate the process by default. A single malformed work item from the sidecar (missing instanceId) will crash the entire worker, taking down all in-flight orchestrations, activities, and entities.
Proposed Fix
Add .catch() handlers to all three wrapper methods that log the error via the existing WorkerLogs infrastructure instead of letting the rejection go unhandled. The .finally() cleanup is preserved to ensure _pendingWorkItems tracking remains correct.
Problem
The
_executeOrchestrator(),_executeActivity(), and_executeEntity()wrapper methods intask-hub-grpc-worker.ts(lines 612-622, 800-810, 882-893) create fire-and-forget promises tracked in_pendingWorkItems. These promises only have.finally()for cleanup but no.catch()handler.The corresponding internal methods (
_executeOrchestratorInternal,_executeActivityInternal,_executeEntityInternal) throw errors before their inner try/catch blocks when validation fails (e.g., missinginstanceId). These early throws produce unhandled promise rejections.Root Cause
In JavaScript,
.finally()does not mark a rejection as handled — only.catch()does. So when:_executeOrchestratorInternalthrows at line 635 (missing instanceId)_executeActivityInternalthrows at line 823 (missing orchestration instance)_executeEntityInternalthrows at line 916 (missing instanceId)...the rejection propagates as unhandled.
Impact
Severity: High. In Node.js 22+ (the minimum required version for this SDK), unhandled promise rejections terminate the process by default. A single malformed work item from the sidecar (missing instanceId) will crash the entire worker, taking down all in-flight orchestrations, activities, and entities.
Proposed Fix
Add
.catch()handlers to all three wrapper methods that log the error via the existingWorkerLogsinfrastructure instead of letting the rejection go unhandled. The.finally()cleanup is preserved to ensure_pendingWorkItemstracking remains correct.