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

Geschlossen
  • Stimmt etwas nicht?
#706 1 Kommentar 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@hln33 arbeitet bereits daran.

Seit 14.9.2026.

  • #778 von @hln33 — offen

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
68/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
java
Bereich
backend, testing

Rechercherichtung

Beginne in CheckpointManager.java, indem du die Verarbeitung von Checkpoint-Antworten und den bestehenden Suspendierungspfad nachverfolgst, der InvocationStatus.PENDING zurückgibt. Überprüfe DurableApiErrorClassifier und den lokalen Runner des Testmoduls. Füge dann Testabdeckung hinzu, die zeigt, dass ein null-Token PENDING zurückgibt, keine weiteren Checkpoint-Aufrufe ausführt und keine Exception auslöst.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

enhancement pkg:sdk project
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

CheckpointManager.java assigns the response token unconditionally:

checkpointToken = response.checkpointToken();

So after a response with no token, checkpointToken is null. The next checkpoint call passes null to the client. The outcome is either a client-side parameter validation exception or a service InvalidParameterValueException: Invalid checkpoint token rejection; I have not verified which. A client-side exception is not an AwsServiceException, so DurableApiErrorClassifier.classifyException never sees it and it propagates as-is. A service rejection is classified per #705: with that fix it is a retryable invocation error and the handler throws; without it, the execution fails. In no case does the SDK return PENDING.

Possible Implementation
  1. After the checkpoint call, if response.checkpointToken() is null, mark the manager as suspended-by-service, stop issuing further checkpoints, and complete any pending pollers so no thread blocks on a checkpoint that will never happen.
  2. Route the outcome through the existing suspension path that returns InvocationStatus.PENDING (the same path used by waits and callbacks).
  3. In-flight operations 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 with a null token produces PENDING, no further checkpoint calls, and no thrown exception.
  5. Testing module: 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: #705 (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 Python SDKs are linked in a comment below.
Vorherrschende Sprache
Java
Sterne
28
Forks
16
Ø Merge
2 T. 59 Min.
Gemergte PRs (30 T.)
62

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus aws/aws-durable-execution-sdk-java

Alle Issues in aws/aws-durable-execution-sdk-java

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.