Poll a step no later than its next timeout so timeouts fire on time - #266
Merged
Merged
Conversation
rdeepak2002
approved these changes
Sep 22, 2026
rdeepak2002
left a comment
rdeepak2002
left a comment
Collaborator
There was a problem hiding this comment.
Overall makes sense to me. I thought about whether there can be any edge cases from weird timeout values but couldn't think of any
rdeepak2002
reviewed
Sep 22, 2026
| Long clockStart = phase.getClockStart(state); | ||
| Long limit = limits.get(phase); | ||
| if (phase.appliesTo(state.getStatus()) && clockStart != null && limit != null) { | ||
| delay = Math.min(delay, Math.max(0, clockStart + limit - now)); |
Collaborator
There was a problem hiding this comment.
optional nit: limit - (now - clockStart) is safer to prevent overflows, but I guess that shouldn't happen since we have a limit of 120 days
Collaborator
Author
There was a problem hiding this comment.
Done, switched to limit - (now - clockStart). It also reads the same way as the timeout check right above it.
akashdw
force-pushed
the
ad/timeout-aware-poll
branch
from
September 22, 2026 03:33
c8958b1 to
126a538
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request type
./gradlew build --write-locksto refresh dependencies)NOTE: Please remember to run
./gradlew spotlessApplyto fix any format violations.Changes in this PR
A step's timeout is only noticed when the step is polled. For steps in a waiting status, and for step runtimes that ask for their own long poll interval, that poll can be a long way off. Both rely on the wakeup mechanism to react to events, and polling is a safety net in case an event is missed, so the interval is set long on purpose, tens of minutes in some deployments. The timeout check then runs on whichever poll happens to come after the deadline, and we have seen steps time out well after the fact: a step with a 4 hour signal wait and a 30 minute poll times out anywhere up to 4h30.
With this change, when the engine schedules the next poll it looks at the deadlines that apply to the step's current status and never schedules past the earliest one. A step polled a minute before its timeout is polled again at the timeout, not thirty minutes later. The regular interval is untouched for any step whose deadline is further away than the interval, which is every step that does not end up timing out.
This applies equally to the fixed per-status intervals from configuration and to the interval a step runtime requests for itself, so a runtime cannot push a poll beyond a timeout either. Steps that are already past their deadline are polled immediately.