JobSnooze accepts negative durations despite documented panic contract
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
从 error.go 开始，JobSnooze 构造函数及其 JobSnoozeError 定义于此；该 issue 链接了确切的行号（L30-L45），并指出缺少对负时长的保护检查。在编写该检查之前，先查看 internal/jobexecutor/job_executor.go 如何消费 snooze 错误，并在改变行为之前在 issue 讨论串中确认预期的契约。完成的标准是 JobSnooze(-duration) 会 panic，而零和正时长仍返回 *river.JobSnoozeError，通过一个采用所提供示例风格的针对性测试验证，并在受影响的包上使用 go test -race 运行。
由索引模型根据 Issue 内容生成。
描述
Problem
JobSnooze documents that it panics when duration < 0, but currently returns a JobSnoozeError with the negative duration instead.
At current default commit ba85f3e01faf0db172882e377e87aabf4f2f07cb, error.go has no negative-duration check. The executor handles snooze errors before normal error/max-attempt handling, computes now + duration, and decrements the attempt count. A negative duration therefore follows the immediate-availability branch rather than the documented validation failure. I have traced that branch but have not run a database-backed execution test.
Reproduction and evidence
A public-API test expecting a panic for JobSnooze(-time.Nanosecond) and JobSnooze(-time.Second) fails in both cases. Controls for JobSnooze(0) and JobSnooze(time.Second) pass and preserve the duration via errors.As to *river.JobSnoozeError.
func TestJobSnoozeRejectsNegativeDuration(t *testing.T) {
t.Parallel()
defer func() {
if recover() == nil {
t.Fatal("expected JobSnooze to panic for a negative duration")
}
}()
_ = river.JobSnooze(-time.Nanosecond)
}
The isolated test ran with Go 1.27.1 and -race -count=1, without a database, Client.Start, or network access. The module version was v0.48.1-0.20261004195309-6cdaf386c3f6. I separately checked that the module's error.go, internal/jobexecutor/job_executor.go, and internal/jobexecutor/job_executor_test.go blobs exactly match the current default commit. This is narrow API reproduction, not a claim that the full current workspace test suite passes.
Merged #1037 explicitly supports zero-duration snoozes and retained the negative-duration panic documentation. Existing executor tests cover scheduled and immediately available snoozes; I did not find a negative-duration constructor test or an existing matching issue/PR in the targeted search.
Proposed scope
Is the documented negative-duration panic still the intended contract? If so, I can add the constructor guard and focused regression tests while preserving zero/positive durations. If negative durations are intentionally equivalent to zero, I would appreciate confirmation before changing behavior; the documentation would need to reflect that instead.
This is separate from the worker-registration atomicity question in #1433. No production code, protocol, database schema, or retry policy has been changed. Investigation and synthetic tests were assisted by OpenAI Codex; the reported results are actual local executions.
- 主要语言
- Go
- 星标
- 5.7k
- 派生
- 187
- 平均合并
- 22 小时 36 分钟
- 30 天内合并 PR
- 89
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
riverqueue/river 的其他 Issue
-
Notifier spins without backoff when the Start context ends by deadline可能已有人在做 @brandur 于 1 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 62/100
riverqueue/river#1493 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 52/100
riverqueue/river#1411 · 1 条评论 ·
维护者通常 1 天内回复
-
Remote JobCancel() can be silently lost while the notifier is reconnecting (no durable-poll fallback)可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 5/5 一周以上 新手友好度 45/100
riverqueue/river#1358 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 35/100
riverqueue/river#1258 · 7 条评论 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 45/100
riverqueue/river#1225 · 14 条评论 ·
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 66/100
-
难度 2/5 1-3 小时 新手友好度 76/100
prime-radiant-inc/evener#4329 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 79/100
openwatersio/aiscast#277 ·
维护者通常 1 天内回复