temporalio / temporalio/sdk-java
TestWorkflowEnvironment schedules the first activity retry immediately
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 433
- Forks
- 249
- Avg merge
- 5d 6h
- Merged PRs (30d)
- 26
Description
Expected Behavior
With a retry policy like:
RetryOptions.newBuilder()
.setInitialInterval(Duration.ofSeconds(10))
.setBackoffCoefficient(2.0)
.build();
I would expect delays of 10, 20, 40, 80, so attempts (including the first one) run at T0, 10, 30, 70, 150.
Actual Behavior
Attempts run at T0, 0, 10, 30, 70 - the first retry gets scheduled immediately.
Steps to Reproduce the Problem
Check out https://github.com/nagl-stripe/sdk-java/commit/b4f764dfdc22102893be1916b325a40322ccd54e - it has a test case that would pass if the actual behavior were the expected behavior
This is very much not-urgent =)
Specifications
- Version: latest
- Platform: TestWorkflowEnviornment
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the test case in commit b4f764dfdc22102893be1916b325a40322ccd54e and inspect how TestWorkflowEnvironment schedules activity retries. Reproduce the retry policy with delays of 10, 20, 40, and 80 seconds, then verify attempts occur at T0, 10, 30, 70, and 150 rather than retrying immediately.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- testing
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100