[Feature]: Exit gracefully with PENDING when a checkpoint response has no CheckpointToken #918

What would you like?

When a checkpoint response arrives without a CheckpointToken, the SDK should treat it as a signal that the service will accept no further checkpoints from this invocation. The SDK should stop issuing checkpoints and end the invocation cleanly with Status: PENDING.

Why PENDING and not FAILED or a thrown error:

• A missing token does not mean the execution is finished. It means this invocation cannot make further progress. The invocation result must not claim the execution finished.
• A thrown error is an invocation failure. Lambda retries it, but the retry has no valid token and can do nothing useful. It also puts an error in customer logs for a condition the SDK understood.
• PENDING is already what the SDK returns for every suspend (wait, scheduled retry, pending callback). This is a suspend: the invocation is done for now and the execution continues later.

Current behavior

The checkpoint manager ignores a missing token (src/utils/checkpoint/checkpoint-manager.ts):

if (response.CheckpointToken) {
  this.currentTaskToken = response.CheckpointToken;
}

So the SDK keeps the consumed token and sends it on the next checkpoint. The service rejects that call with InvalidParameterValueException: Invalid checkpoint token. With the fix for #917 in place, that is classified as an invocation error and the handler throws. So the invocation ends with a Lambda error instead of a clean PENDING. Without the fix for #917, it fails the execution.

Possible Implementation

1. Add TerminationReason.EXECUTION_SUSPENDED_BY_SERVICE (name open) and classify it "suspend" in TERMINATION_CLASS. withDurableExecution then returns { Status: PENDING } through the existing suspend path with no further change.
2. In CheckpointManager, when a checkpoint response has no CheckpointToken, call terminationManager.terminate({ reason: ... }) and stop draining the checkpoint queue. There is no token to send, so any further checkpoint is guaranteed to fail.
3. In-flight operations in the invocation are abandoned, not checkpointed. On the next invocation they replay. This is correct for AT_LEAST_ONCE steps. AT_MOST_ONCE steps whose START landed in the last accepted checkpoint will not run again, which is the defined semantics of AT_MOST_ONCE.
4. Unit test: a checkpoint response without CheckpointToken produces Status: PENDING, no further checkpoint calls, and no thrown error.
5. Testing SDK: the local checkpoint server needs a way to omit the token on a chosen checkpoint so customers can test their handlers against this path.

Is this a breaking change?

No. The SDK's response set is unchanged; a new internal termination reason is added.

Additional Context

• Prerequisite: [Bug]: Invalid checkpoint token misclassified as execution failure (message case mismatch) #917 (message-case bug in stale-token classification). That fix is the fallback path whenever the missing token is not detected, so it should land first.
• Sibling issues in the Python and Java SDKs are linked in a comment below.