aws / aws/aws-durable-execution-sdk-python
[Feature]: Exit gracefully with PENDING when a checkpoint response has no CheckpointToken
- Vorherrschende Sprache
- Python
- Sterne
- 53
- Forks
- 25
- Ø Merge
- 1 T. 19 Std.
- Gemergte PRs (30 T.)
- 40
Beschreibung
### 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 loop already detects a missing token on a non-empty batch (`state.py`, `_process_checkpoint_batch`), but it reads the missing token as "the execution reached a terminal state":
```python
if output.checkpoint_token:
current_checkpoint_token = output.checkpoint_token
elif updates:
execution_completed = True
```
It then calls `_settle_after_execution_completed()`, which stops checkpointing and settles every queued operation with `OrphanedChildException`. The handler thread keeps running. On its next durable call, `_reject_if_execution_completed` raises `OrphanedChildException`. That class extends `BaseException`, and `execution.py` has no handler for it. So the exception propagates out of the Lambda handler as an unhandled error. The invocation fails; the SDK never returns PENDING. If the handler needs no further durable call it returns SUCCEEDED normally.
So Python already has the detection point. What is missing is the classification: a missing token on a non-empty batch is not always "execution completed"; it can also mean "no further checkpoints from this invocation, execution continues later."
### Possible Implementation
1. At the `elif updates:` branch, treat the missing token as a suspend rather than as "execution completed". A completed execution never invokes the handler again, so answering PENDING for it is harmless; a suspended one needs PENDING.
2. Raise `SuspendExecution` (or a new sibling) in the handler thread instead of `OrphanedChildException` when the missing token is observed. `execution.py` already maps `SuspendExecution` to `InvocationStatus.PENDING`.
3. Keep `_settle_after_execution_completed` semantics for queued operations: they cannot be checkpointed, so they are abandoned and replay on the next invocation. 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 `checkpoint_token` on a non-empty batch produces `status: PENDING`, no further checkpoint calls, and no raised exception.
5. Testing SDK: the local runner 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: #721 (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 JS and Java SDKs are linked in a comment below.
Beitragsleitfaden
Rechercherichtung
Beginnen Sie in state.py bei _process_checkpoint_batch und prüfen Sie execution.py auf SuspendExecution und das vorhandene PENDING-Mapping. Fügen Sie den Unit-Test für einen nicht leeren Batch hinzu oder aktualisieren Sie ihn, dessen Checkpoint-Antwort checkpoint_token nicht enthält, und prüfen Sie anschließend die Checkpoint-Steuerung des lokalen Runners. Erledigt ist die Aufgabe, wenn der Aufruf PENDING zurückgibt, keine weiteren Checkpoint-Aufrufe ausführt und keine unbehandelte Ausnahme auslöst.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- aws, python
- Bereich
- backend, cloud
- Issue-Typ
- Feature
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Aktivitätsstatus
- Aktiv
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 62/100