JobSnooze accepts negative durations despite documented panic contract

Fechada Para iniciantes
  • Algo errado?
#1,454 6 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

@mohammednumaan já está trabalhando nisso.

Desde 18/10/2026.

Avaliação

Dificuldade
2/5
Tempo estimado
1-3 horas
Facilidade para iniciantes
72/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
go
Domínio
backend

Direção de pesquisa

Comece em error.go, onde o construtor JobSnooze e seu JobSnoozeError são definidos; o issue vincula as linhas exatas (L30-L45) e aponta a falta de uma guarda para durações negativas. Verifique como internal/jobexecutor/job_executor.go consome os erros de snooze antes de escrever a guarda, e confirme o contrato pretendido na thread do issue antes de alterar o comportamento. Pronto significa que JobSnooze(-duration) provoca um panic, enquanto durações zero e positivas continuam retornando *river.JobSnoozeError, verificado por um teste focado no estilo do fornecido, executado com go test -race nos pacotes afetados.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Go
Estrelas
5.8k
Forks
194
Merge médio
1d 4h
PRs com merge (30d)
124

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de riverqueue/river

Todas as issues de riverqueue/river

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.