Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

test server: retrying activity never times out by ScheduleToClose when its expiration falls on a whole second (`getNanos() != 0` guard in `TestServiceRetryState`)

Aberta Para iniciantes
  • Algo errado?
#3,134 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
2/5
Tempo estimado
1-3 horas
Facilidade para iniciantes
78/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
java
Domínio
backend

Direção de pesquisa

Leia TestServiceRetryState.getBackoffIntervalInSeconds no servidor de teste Java, especialmente a verificação de expiração descrita na issue. Compare o horário da próxima tentativa com o horário de expiração, mesmo quando os nanossegundos forem zero, e depois execute os testes relevantes do estado de repetição. O trabalho estará concluído quando uma atividade atingir o timeout em ScheduleToClose, independentemente de a expiração cair em um segundo exato.

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

Descrição

Summary

In the Java test server (temporal-test-server), an activity that keeps failing with a retryable error is supposed to stop retrying once the next attempt would start after its ScheduleToClose deadline. In TestServiceRetryState.getBackoffIntervalInSeconds this check is guarded by expirationTime.getNanos() != 0:

if (expirationTime.getNanos() != 0
    && Timestamps.compare(nextScheduleTime, expirationTime) > 0) {
  return new BackoffInterval(RetryState.RETRY_STATE_TIMEOUT);
}

The test server's clock has millisecond precision, so the expiration timestamp has nanos == 0 whenever the activity was scheduled exactly on a whole second (≈1 in 1000 schedules). In that case the check is skipped, and nothing else closes the activity: the ScheduleToClose timer is bound to the attempt number at scheduling time and is discarded as outdated after the first retry. The activity then retries forever (we observed 362 attempts at 20 s intervals well past a 2 h deadline), and the workflow never completes.

The guard looks unnecessary: the constructor already maps "no expiration" to Timestamps.MAX_VALUE, so comparing against it is safe.

Reproduction

Minimal workflow (Kotlin, SDK 1.25.1, TestWorkflowEnvironment with time skipping):

  • activity always throws a retryable ApplicationFailure;
  • ScheduleToCloseTimeout = 2h, RetryOptions(initialInterval = 20m, backoffCoefficient = 1.0), no maximumAttempts;
  • workflow catches ActivityFailure and returns.

Running many independent executions and waiting 5 s (wall clock) for each result:

test server executions never completed ActivityTaskScheduled.eventTime.nanos of the stuck ones
1.25.1 4514 4 0 in all 4
1.40.0 409 1 0
1.25.1 with the getNanos() != 0 && part removed 12000 0 (11 schedules had nanos = 0) —

A deterministic reproduction is possible by freezing the test server clock on a whole second (we did it with a test-scoped TestServicesStarter variant using Clock.fixed(...)): without the change the activity never closes; with it, it closes by RETRY_STATE_TIMEOUT.

Expected

RETRY_STATE_TIMEOUT whenever the next attempt would be scheduled after the expiration time, regardless of the sub-second part of the expiration timestamp.

Suggested fix

if (Timestamps.compare(nextScheduleTime, expirationTime) > 0) {
  return new BackoffInterval(RetryState.RETRY_STATE_TIMEOUT);
}

Versions checked: 1.25.1, 1.26.0, 1.28.0, 1.30.0, 1.34.0, 1.36.0, 1.40.0 — the same condition is present. We currently work around it by shadowing the class in our test classpath.

Linguagem predominante
Java
Estrelas
433
Forks
257
Merge médio
2d 18h
PRs com merge (30d)
24

Preparar o ambiente

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 temporalio/sdk-java

Todas as issues de temporalio/sdk-java

Issues semelhantes

Mais issues de Java

Receba novas issues na sua caixa de entrada

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