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

Allow a timer summary on Workflow.sleep and Workflow.await with timeout

未关闭
#3,108 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@sangkyoonnam 已经在做这个了。

开始于 2026年10月1日。

  • #3109 来自 @sangkyoonnam —— 未关闭

评估

难度
4/5
预计耗时
3-5 天
新手友好度
55/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
java

调研方向

Start with SyncWorkflowContext.java:1368-1401 and trace the Workflow sleep/await APIs into WorkflowOutboundCallsInterceptor, its Base, and TracingWorkerInterceptor. Add the proposed TimerOptions overloads while preserving both CANCEL_AWAIT_TIMER_ON_CONDITION branches, then verify replay compatibility with an old history that has no timer summary.

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

描述

enhancement

Is your feature request related to a problem? Please describe.

Workflow.newTimer(Duration, TimerOptions) can set a summary, but Workflow.sleep(Duration) and Workflow.await(Duration, Supplier) create their timers with default options (SyncWorkflowContext.java:1368-1401). I'd like sleep and timed await to accept TimerOptions, so a workflow waiting on a human approval with a timeout can label that timer. Today the workaround for sleep is Workflow.newTimer(d, options).get(). For a timed await you have to race the condition against your own timer and cancel it yourself, which is what await already does internally. temporalio/features#669 tracks this across SDKs.

Describe the solution you'd like

// Workflow
public static void sleep(Duration duration, TimerOptions options);
public static boolean await(Duration timeout, TimerOptions options, Supplier<Boolean> unblockCondition);

// WorkflowOutboundCallsInterceptor (+ Base)
void sleep(Duration duration, TimerOptions options);
boolean await(Duration timeout, TimerOptions options, String reason, Supplier<Boolean> unblockCondition);

This follows #2218, which added newTimer(Duration, TimerOptions) to the interceptor, its Base, and TracingWorkerInterceptor. The interface is @Experimental, but direct implementers still get a source change. Replay checks the timer command type and ID, not its user metadata, so I don't expect this to need a new SDK flag. I haven't verified that against a replay yet. Both await branches under CANCEL_AWAIT_TIMER_ON_CONDITION (enabled in #3099) would keep their behavior.

Other SDKs: Python has workflow.sleep(..., summary=) and workflow.wait_condition(..., timeout_summary=). Go has workflow.AwaitWithOptions with AwaitOptions{Timeout, TimerOptions}. PHP added AwaitOptions to Workflow::awaitWithTimeout() in temporalio/sdk-php#805.

Describe alternatives you've considered

An AwaitOptions class like Go and PHP. It leaves room for more await settings but adds a type for one field today.

Additional context

This doesn't cover sleep(long, ...) or timed Promise.get, which also goes through await. I'd like to implement it, with a replay test against an old history that has no summary. I'll go with the TimerOptions overloads unless you'd rather have AwaitOptions.

主要语言
Java
星标
433
派生
257
平均合并
2 天 18 小时
30 天内合并 PR
24

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

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

temporalio/sdk-java 的其他 Issue

查看 temporalio/sdk-java 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

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