Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Track skipped final-result checkpoint acknowledgment and late worker admission

未关闭
  • 哪里不对？
#787 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
8/100
Issue 类型
缺陷
描述清晰度
需要澄清
活跃度
活跃
技术栈
java
领域
backend

调研方向

Start with the result path in sdk/src/main/java/software/amazon/lambda/durable/execution/DurableExecutor.java (root outcome selection and handleLargePayload), then CheckpointManager.checkpointBatch and ApiRequestDelayedBatcher. The issue is a static-analysis tracking report with no reproduction, and it asks for arbitration and admission guarantees to be defined first. Done means those guarantees are specified and the suspected interleavings are validated, which needs maintainer design input.

由索引模型根据 Issue 内容生成。

描述

needs-triage

Summary

Track the potential loss of an oversized execution result when its final checkpoint is skipped, together with the related late user-worker admission boundary. This is the follow-up requested in the #767 review.

This report records static code-path analysis, not a runtime-confirmed reproduction. The reviewer explicitly noted that the trace has not been run. The concern applies to current main 1064d0ec32e5b1650b4fa08e65ca960361c7cd1b, independently of the fallback-root telemetry change.

Potential failure path

  1. The root handler outcome is selected before result preparation.
  2. A continuation can subsequently fail and complete invocation control before or during preparation.
  3. CheckpointManager.checkpointBatch can return without sending an update when that control is already exceptional.
  4. The batcher can nevertheless complete the update's observation normally.
  5. For an output beyond the inline result limit, handleLargePayload treats that completion as persistence and returns an empty inline result.

If the described interleaving is reachable, the response could report SUCCEEDED with an empty inline result while its required EXECUTION/SUCCEED checkpoint was never stored. Closing new continuation registration before serialization narrows admission but does not itself prove delivery of that mandatory checkpoint.

Related admission boundary

Review r4262386190 identifies an already-admitted continuation that passes a closing check, waits for earlier work or dispatch, and then starts a fresh user worker after root selection. Registration admission and later worker admission need to be distinguished; a registration gate alone is not a guarantee that all accepted work has stopped.

Follow-up requirements

  • A required checkpoint that was not sent must not be acknowledged as persisted. An empty inline result used for durable result offloading must correspond to confirmed checkpoint completion.
  • Validate the suspected result-preparation and worker-admission interleavings described in the linked reviews, including caller outcome, persisted result and replay behavior. No dynamic reproduction is claimed in this issue.
  • Define success/control arbitration and admission guarantees explicitly before adding a stronger global outcome or cleanup policy. Preserve original failures and the behavior of completed replayed work.

Earlier discussions: r4233196696, r4233420625, and r4262385920. This is a tracking report; no automated implementation is requested.

主要语言
Java
星标
28
派生
15
平均合并
1 天 13 小时
30 天内合并 PR
41

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

aws/aws-durable-execution-sdk-java 的其他 Issue

查看 aws/aws-durable-execution-sdk-java 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。