Expected Behavior
When the service rejects a checkpoint call with InvalidParameterValueException because the checkpoint token is stale (a newer invocation superseded this one), the SDK should classify the error as an invocation failure (retryable). The current invocation ends, and the service starts a fresh invocation with a fresh token. The execution itself continues.
Actual Behavior
The SDK classifies the error as an execution failure (non-retryable). So a stale checkpoint token fails the whole durable execution every time.
Root Cause
The classifier matches the error message with a case-sensitive prefix check against "Invalid Checkpoint Token". The service emits "Invalid checkpoint token" (lowercase c and t). The prefix check never matches. The error falls through to the generic 4xx branch, which is classified as an execution failure.
SDK constant (sdk/src/main/java/software/amazon/lambda/durable/util/DurableApiErrorClassifier.java):
|
private static final String INVALID_CHECKPOINT_TOKEN_MESSAGE_PREFIX = "Invalid Checkpoint Token"; |
private static final String INVALID_CHECKPOINT_TOKEN_MESSAGE_PREFIX = "Invalid Checkpoint Token";
Used in classifyException() via message.startsWith(INVALID_CHECKPOINT_TOKEN_MESSAGE_PREFIX). The Javadoc also documents the wrong string (4xx + "Invalid Checkpoint Token" → retryable).
Steps to Reproduce
- Have the service return a 4xx
InvalidParameterValueException whose message starts with Invalid checkpoint token (the real service message).
- Pass it through the SDK error classifier.
- Observe it is classified as an execution (non-retryable) error rather than an invocation (retryable) error.
The existing unit tests do not catch this. They construct the error with the message "Invalid Checkpoint Token: token expired", which matches the SDK constant rather than the service constant.
Proposed Fix
- Change the SDK constant to
"Invalid checkpoint token" so it matches the service.
- Consider a case-insensitive comparison to protect against future drift.
- Update the unit tests to use the real service message.
Related
Same defect exists in all three SDKs; each gets its own issue.
- JS: aws/aws-durable-execution-sdk-js
- Python: aws/aws-durable-execution-sdk-python
- Java: aws/aws-durable-execution-sdk-java
SDK Version
main (7f1a73c)
Expected Behavior
When the service rejects a checkpoint call with
InvalidParameterValueExceptionbecause the checkpoint token is stale (a newer invocation superseded this one), the SDK should classify the error as an invocation failure (retryable). The current invocation ends, and the service starts a fresh invocation with a fresh token. The execution itself continues.Actual Behavior
The SDK classifies the error as an execution failure (non-retryable). So a stale checkpoint token fails the whole durable execution every time.
Root Cause
The classifier matches the error message with a case-sensitive prefix check against
"Invalid Checkpoint Token". The service emits"Invalid checkpoint token"(lowercasecandt). The prefix check never matches. The error falls through to the generic 4xx branch, which is classified as an execution failure.SDK constant (
sdk/src/main/java/software/amazon/lambda/durable/util/DurableApiErrorClassifier.java):aws-durable-execution-sdk-java/sdk/src/main/java/software/amazon/lambda/durable/util/DurableApiErrorClassifier.java
Line 51 in 7f1a73c
Used in
classifyException()viamessage.startsWith(INVALID_CHECKPOINT_TOKEN_MESSAGE_PREFIX). The Javadoc also documents the wrong string (4xx + "Invalid Checkpoint Token" → retryable).Steps to Reproduce
InvalidParameterValueExceptionwhose message starts withInvalid checkpoint token(the real service message).The existing unit tests do not catch this. They construct the error with the message
"Invalid Checkpoint Token: token expired", which matches the SDK constant rather than the service constant.Proposed Fix
"Invalid checkpoint token"so it matches the service.Related
Same defect exists in all three SDKs; each gets its own issue.
SDK Version
main (7f1a73c)