Skip to content

[SDK Sentinel] Allow activity retry delay test to complete - #3010

Draft
sdk-sentinel-bot wants to merge 1 commit into
temporalio:mainfrom
sdk-sentinel-forks:automation/sdk-sentinel/ci-flake/java/31847451911-1-034748df6ce1
Draft

[SDK Sentinel] Allow activity retry delay test to complete#3010
sdk-sentinel-bot wants to merge 1 commit into
temporalio:mainfrom
sdk-sentinel-forks:automation/sdk-sentinel/ci-flake/java/31847451911-1-034748df6ce1

Conversation

@sdk-sentinel-bot

Copy link
Copy Markdown

Caution

This draft contains untrusted AI-generated code. Do not approve or run CI until a maintainer has reviewed the diff. SDK Sentinel verified that GitHub Actions remained approval-gated with zero executable jobs when this PR was opened.

Summary

The Java 11 CLI-backed suite timed out in ActivityNextRetryDelayTest.activityNextRetryDelay while waiting for its workflow result ([first captured failure](https://github.com/temporalio/sdk-java/actions/runs/31753323140/job/94623675320)). No preceding equivalent success was captured. Breaking changes: none. Server PR: none.

Root cause

The test intentionally requests one-, two-, and three-second retry delays but inherits a ten-second rule deadline. Service and scheduler latency stretched the first retry interval beyond five seconds, leaving too little budget for the final attempt; JUnit interrupted the history long poll.

Fix

Give this test a 30-second rule deadline. Retry behavior and the existing timing assertions remain unchanged, while transient service latency can no longer terminate the test before those assertions run.

Validation

The focused class passed on Java 11 against a loopback Temporal CLI, and an adjusted spotlessCheck testClasses passed. Exact repository validation was attempted but the sandbox blocked writes to .git/modules; the trusted unchanged baseline passed it. The pinned CLI job and trusted patch validation remain required.

Validation status: validation-incomplete

  • Flake confidence: high
  • Fix confidence: medium
  • Value: medium
  • Patch scope: standard — 1 changed file; 786 B
  • Local reproduction: not-reproduced — The unchanged focused CLI-backed class passed locally; the captured load-induced delay did not recur.
  • Regression coverage: pass-after-only — The existing focused Java 11 CLI-backed test passed after the test-scoped timeout change; no new test was required.
  • Unchanged baseline (Gradle formatting and test-source compilation) — passed
  • Independent candidate (Gradle formatting and test-source compilation) — did not pass (failure)

Investigator-run checks

  • USE_EXTERNAL_SERVICE=true TEMPORAL_SERVICE_ADDRESS=127.0.0.1:7233 ./gradlew --offline --no-daemon :temporal-sdk:test --tests 'io.temporal.activity.ActivityNextRetryDelayTest' -PtestJavaVersion=11 -x :temporal-serviceclient:initSubmodules -x :temporal-serviceclient:updateSubmodules -x :temporal-sdk:compileJava17Java -x :temporal-sdk:compileJava21Java — passed; 1 attempt(s). Both activity and local-activity cases passed on Java 11 against the loopback Temporal CLI.
  • .ci-flake-runtime/input/validate.sh — failed; 1 attempt(s). Failed before candidate compilation because the sandbox denied writes to .git/modules; the trusted unchanged-checkout baseline passed the same command.
  • ./gradlew --offline --no-daemon spotlessCheck testClasses -x test -x :temporal-serviceclient:initSubmodules -x :temporal-serviceclient:updateSubmodules — passed; 1 attempt(s). Formatting and test-class compilation passed when only the sandbox-blocked submodule metadata tasks were excluded.

Required target CI

  • Trusted patch validation with writable submodule metadata.
  • Continuous Integration / Unit test with CLI using Java 11 and the pinned dev-server profile.

Residual risks

  • The precise concurrent-suite latency was not reproduced.
  • Local validation used Temporal CLI 1.7.2 rather than CI's pinned 1.7.4.
  • The canonical candidate check requires trusted execution because this sandbox cannot update .git/modules metadata.

Automation provenance

If this finding should not be fixed, apply the sdk-sentinel:false-positive label and close the PR. Sentinel will suppress the finding until its affected source changes.

SDK Sentinel recurrence history

  • Unique failed CI run attempts: 1
  • First occurrence: 2026-08-13 23:33 UTC
  • Latest occurrence: 2026-08-13 23:33 UTC
  • Recent occurrences:

@CLAassistant

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants