[Bug]: Stale checkpoint token fails the execution; no stale-token carve-out in classifyCheckpointError #6

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 end the current invocation as an invocation failure. The service then starts a fresh invocation with a fresh token, and the execution continues.

Actual Behavior

A stale checkpoint token fails the whole durable execution every time.

Root Cause

Two things combine (alpha branch at 7183f03; main is README-only):

1. classifyCheckpointError in durable/checkpoint_errors.go has no carve-out for the stale-token rejection. Every smithy.APIError with FaultClient other than TooManyRequestsException is non-retryable. The other SDKs carve out InvalidParameterValueException with the message prefix Invalid checkpoint token (note the case: the service constant is "Invalid checkpoint token", lowercase c and t; several sibling SDKs got this wrong).
2. Even a retryable classification would not help as the code stands. checkpointer.checkpoint in durable/checkpoint.go retries in-process with the same cp.token, then returns lastErr. The step returns that error to the handler, and durable/handler.go turns any handler error into Status: FAILED. There is no path by which a checkpoint failure ends the invocation with an error return (which is what makes the service re-invoke).

Steps to Reproduce

1. Have the service return a 400 InvalidParameterValueException whose message starts with Invalid checkpoint token.
2. Pass it through classifyCheckpointError.
3. Observe Retryable() is false, the step returns the error, and the invocation responds Status: FAILED.

Proposed Fix

1. In classifyCheckpointError, recognize ErrorCode() == "InvalidParameterValueException" with a message starting with Invalid checkpoint token (case-insensitive to protect against drift) as a stale-token rejection.
2. Do not retry a stale token in-process; the token will never become valid again. Instead, terminate the checkpointer and end the invocation with an error return from the Lambda handler (an invocation failure), not a FAILED response.
3. Unit test with the real service message string.

Related

Same defect exists in the other SDKs; each has its own issue. Sibling links are in a comment below.

SDK Version

alpha (7183f03)