You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Feature]: Validate subType before the first checkpoint #1097
StepOptions.subType, CallbackOptions.subType, and ChildContextOptions.subType document the service constraint (1 to 32 characters from [a-zA-Z0-9-_]) but the SDK does not check it. The service rejects an invalid value with a 400 ValidationException on the first checkpoint.
For a step with the default AT_LEAST_ONCE_PER_RETRY semantics, the START checkpoint is sent without waiting for the response, so the step body runs before the rejection arrives. The execution then fails. A typo in a subtype therefore runs the side effect once, for example a payment, and then fails the execution.
Please validate subType when the option is given, and throw before any checkpoint is sent. The Python SDK does this in aws/aws-durable-execution-sdk-python#837: the config raises a validation error for a value outside the documented constraint; empty and undefined select the default.
Possible Implementation
Check length and characters when the handler reads the option, before building the operation. No regex is needed; a length check and a character-set check suffice.
Is this a breaking change?
No. Only values the service already rejects are affected.
Thanks for the detailed report. The limits on subType (and on operation names) belong to the service, and the SDK leaves them to the service, as it does for payload size. Duplicating them in the SDK would mean keeping two copies of the service contract in sync.
Instead, #1159 adds an ESLint rule, valid-operation-identifiers, to the recommended config. It reports a literal subType outside [a-zA-Z0-9-_] or over 32 characters, and a literal operation name outside printable ASCII or over 256 characters. That catches the typo in the editor, before deploy, so the step body never runs with a bad value. Values built at run time are still checked by the service.
Activity
ParidelPooya commentedon Nov 1, 2026
Thanks for the detailed report. The limits on
subType(and on operation names) belong to the service, and the SDK leaves them to the service, as it does for payload size. Duplicating them in the SDK would mean keeping two copies of the service contract in sync.Instead, #1159 adds an ESLint rule,
valid-operation-identifiers, to the recommended config. It reports a literalsubTypeoutside[a-zA-Z0-9-_]or over 32 characters, and a literal operation name outside printable ASCII or over 256 characters. That catches the typo in the editor, before deploy, so the step body never runs with a bad value. Values built at run time are still checked by the service.Closing in favor of #1159.
feat(eslint-plugin): report an operation name or subType the service …