Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

[Bug]: Enforce invocation deadlines while awaiting owner cleanup

Ouverte
  • Quelque chose ne va pas ?
#838 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@zhongkechen y travaille déjà.

Depuis le 24/9/2026.

  • #733 par @zhongkechen — ouverte

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
1/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
aws, java
Domaine
backend, distributed-systems

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Java
Étoiles
28
Forks
16
Merge moyen
2 j 59 min
PR mergées (30 j)
62

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de aws/aws-durable-execution-sdk-java

Toutes les issues de aws/aws-durable-execution-sdk-java

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.