[Bug]: Enforce invocation deadlines while awaiting owner cleanup

Abierto
  • ¿Algo no está bien?
#838 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@zhongkechen ya está trabajando en esto.

Desde el 24/9/2026.

  • #733 de @zhongkechen — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
1/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
aws, java
Área
backend, distributed-systems

Línea de trabajo

The issue identifies PR #733 as the implementation and says it should be resolved when that PR merges; start by reviewing #733 and its regression tests for admission, serialization, cancellation races, and owner draining. The issue lists deadline cutoffs, cancellation and cleanup behavior, and lifecycle failure precedence as expected behavior, but reports no deployed LMI acceptance run. It is done when the listed acceptance criteria pass and the remaining LMI work stays tracked in #726.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug pkg:sdk
Scope

This issue separates the deadline and cancellation work implemented by #733 from the remaining LMI limitations in #726. PR #733 is open; this issue should be resolved when that implementation merges.

The implementation enforces admission cutoffs and requests cooperative cancellation while continuing to await actual owner cleanup. It does not establish a hard bound on caller return or worker reclamation.

Problem

Invocation deadline exhaustion must stop new user callbacks and checkpoint requests and select an invocation-level retryable failure. Merely rejecting one operation is insufficient: a handler can catch that rejection, return a fallback, and otherwise publish success. Cancellation must also reach admitted work without allowing descendants registered during draining to miss the cancellation broadcast.

Introducing deadline cancellation must preserve the SDK's existing result and failure semantics. Cancellation can race input/output serialization, checkpoint acknowledgment, metadata delivery, and owner cleanup. Those races must not discard JVM fatal errors, hide unrelated delivery failures, replace the original lifecycle cause, or report a successful End event while the caller receives a retryable failure.

Main already contains the invocation task registry and handler-owned Start/End ordering through merged #782, which incorporated #731 and #728. Those are prerequisites preserved by #733, rather than new work attributed to this issue.

Expected Behavior
  • Capture the invocation's remaining time and use monotonic cutoffs for user-work admission, checkpoint requests, and cancellation decisions. A caught admission rejection cannot turn an expired invocation into a successful fallback.
  • On deadline exhaustion, caller interruption, or cleanup-grace expiry, request cancellation of this invocation's admitted work. Fence descendant admission during cancellation and recheck operation/task registration after insertion so no waiter or actual-task record misses cancellation. Preserve ordinary graceful descendant admission and caller ownership of shared executors.
  • Continue waiting for actual task/owner exit, admitted continuations and checkpoint/poll transport, and the matching End on its owner before returning. Attempt the required cleanup stages despite interruption and restore the caller's interrupt flag.
  • Reuse the first recorded lifecycle failure for cancellation broadcasts, End, and caller completion. Retain later cleanup interruptions and SDK-generated owner-drain errors as diagnostics. Synchronous admission/dispatch rejection must retain its original exception without try-with-resources self-suppression.
  • Preserve JVM fatal identity and precedence, including input deserialization crossing the admission cutoff and output serialization racing cancellation. Acknowledged terminal results outrank a lifecycle cutoff but do not suppress unrelated metadata/delivery failures; preserve application exception identity and wrapper semantics.
  • Recheck recorded cancellation before terminal End emission. An unacknowledged result serialized after cancellation must report RETRYING to plugins/OTel. Preserve already-selected PENDING outcomes, acknowledged results, replay identities, stored results/failures, and checkpoint formats.
Acceptance Criteria
  • Deadline and checkpoint admission regressions reject late work, including when the handler catches the rejection or a plugin/serializer delays the next callback.
  • Queued-root cancellation, draining descendants, and registration racing the cancellation broadcast settle without admitting late work or leaving pending owner/waiter records.
  • Caller interruption and deadline/cleanup expiry request cancellation while caller return still waits for actual owner exit, admitted transport, and End.
  • Early admission/dispatch errors, captured input fatals, cancellation-time serializer fatals, and acknowledged-result metadata failures retain their required exception identity and precedence.
  • Cancellation during result serialization produces RETRYING End/OTel output; canonical lifecycle failure identity survives subsequent cleanup and owner-drain errors.
  • Normal success, selected PENDING/retry outcomes, graceful descendant admission, shared-executor ownership, replay, and checkpoint ordering retain their existing behavior.
  • Document that cancellation allowances do not bound actual caller return or reclaim non-cooperative workers, and keep the remaining LMI acceptance work in #726.
Implementation and Validation

Implementation: #733, current head 318d78b3c97372f4e688d4b26348c04355834c76 at scope extraction.

The PR contains public SDK regression tests for admission, serialization, acknowledged delivery, cancellation-registration races, canonical lifecycle failures, and owner-drain reporting, plus tests with both real OTel plugin views. Its description reports full Java 17 and Java 25 reactor validation and packaged-artifact controls; see #733 for the exact tested snapshots and results. No new deployed LMI acceptance run is claimed.

Remaining Work Tracked Elsewhere

#726 retains hard cleanup/return bounds, recovery of LMI runtime slots and workers under non-cooperative work, shared/nested fixed-pool starvation, and deployed LMI acceptance. Invocation-owned executor isolation is proposed separately in #735; arbitrary nested bounded-pool starvation remains outside that partial mitigation.

Lenguaje dominante
Java
Estrellas
28
Forks
16
Merge medio
2 d 59 min
PR fusionados (30 d)
62

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de aws/aws-durable-execution-sdk-java

Todos los issues de aws/aws-durable-execution-sdk-java

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.