Time skip to StickyWorkerUnavailable #9287
Draft
stephanos wants to merge 1 commit intotemporalio:mainfrom
Draft
Conversation
5ec25dc to
1a70768
Compare
stephanos
commented
Feb 11, 2026
| s.NoError(err) | ||
|
|
||
| s.Logger.Info("Sleep 10+ seconds to make sure stickyPollerUnavailableWindow time has passed.") | ||
| time.Sleep(10*time.Second + 100*time.Millisecond) //nolint:forbidigo |
Contributor
Author
There was a problem hiding this comment.
So funny thing; this doesn't even work. The 10s are being waited on for nothing as the sticky task queue is never actually created since there's never a poller.
4d5a512 to
99a3741
Compare
99a3741 to
56d4f09
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
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.
What changed?
timepackage in Matching with virtualsystemClock.taskClockto Matching to be able to forceStickyWorkerUnavailableto trigger asap.time.Sleep(10*time.Second)inTestWorkflowUpdateSuitewith time skipping.Note that (1) can also be a separate PR; if that helps.
Why?
Test runtime before: 10.21s
Test runtime after: 1.3s
There's some extra overhead for starting the cluster; but as we can see here, it's a worthwhile tradeoff.
How did you test it?
Potential risks
taskClockisn't used everywhere it could yet. This might cause confusion since certain things you might expect to be time-skippable won't work. But you have to start somewhere; blocking this effort on identifying every single location first will be difficult.Advancing
taskClockin tests requires a dedicated cluster. This makes its use expensive. Either we accept that it's a rare use case; or if not, could consider a namespace-aware timesource (provider).