Problem
The signalEntity() and getEntity() methods on TaskHubGrpcClient lack the input validation guards that all comparable public API methods have. Without validation, passing null or undefined for the required id parameter produces a confusing TypeError: Cannot read properties of null (reading 'toString') instead of a clear, actionable error message.
Affected methods:
signalEntity(id, operationName, ...) — no validation for id or operationNamegetEntity(id, ...) — no validation for id
File: packages/durabletask-js/src/client/client.ts, lines 991–1037 (signalEntity) and 1046–1072 (getEntity)
Root Cause
These entity methods were added without the input validation pattern that already exists in other client methods. The pattern is consistent across:
raiseOrchestrationEvent() — validates instanceId and eventNameterminateOrchestration() — validates instanceIdsuspendOrchestration() — validates instanceIdresumeOrchestration() — validates instanceIdgetOrchestrationHistory() — validates instanceId
But signalEntity() and getEntity() were not given the same treatment.
Proposed Fix
Add validation guards to both methods matching the established pattern:
signalEntity(): validate id (required) and operationName (required, non-empty)getEntity(): validate id (required)
Impact
Severity: Medium — affects developer experience for entity API users. Without validation, invalid calls crash with unhelpful TypeError messages that don't indicate which parameter is wrong or what value was expected. This slows debugging, especially for users new to the SDK.
Problem
The
signalEntity()andgetEntity()methods onTaskHubGrpcClientlack the input validation guards that all comparable public API methods have. Without validation, passingnullorundefinedfor the requiredidparameter produces a confusingTypeError: Cannot read properties of null (reading 'toString')instead of a clear, actionable error message.Affected methods:
signalEntity(id, operationName, ...)— no validation foridoroperationNamegetEntity(id, ...)— no validation foridFile:
packages/durabletask-js/src/client/client.ts, lines 991–1037 (signalEntity) and 1046–1072 (getEntity)Root Cause
These entity methods were added without the input validation pattern that already exists in other client methods. The pattern is consistent across:
raiseOrchestrationEvent()— validatesinstanceIdandeventNameterminateOrchestration()— validatesinstanceIdsuspendOrchestration()— validatesinstanceIdresumeOrchestration()— validatesinstanceIdgetOrchestrationHistory()— validatesinstanceIdBut
signalEntity()andgetEntity()were not given the same treatment.Proposed Fix
Add validation guards to both methods matching the established pattern:
signalEntity(): validateid(required) andoperationName(required, non-empty)getEntity(): validateid(required)Impact
Severity: Medium — affects developer experience for entity API users. Without validation, invalid calls crash with unhelpful
TypeErrormessages that don't indicate which parameter is wrong or what value was expected. This slows debugging, especially for users new to the SDK.