refactor(temporal): extract workflow registration into WorkflowRegistry and TemporalWorkers - #2322
Open
lschim wants to merge 2 commits into
Open
refactor(temporal): extract workflow registration into WorkflowRegistry and TemporalWorkers#2322lschim wants to merge 2 commits into
lschim wants to merge 2 commits into
Conversation
lschim
changed the title
lschim
marked this pull request as draft
August 13, 2026 09:00
lschim
force-pushed
the
refactor/split-workflow-registration
branch
6 times, most recently
from
August 14, 2026 15:57
e03a03a to
3fee0c8
Compare
…rlocutor WorkflowRegistry holds what to serve and on which queue, TemporalWorkers starts the workers. Discovery no longer drops workflows outside the worker's group, so the queues a process serves are chosen at startup rather than at discovery.
This value requires to be bigger than one because of the sticky queues mechanism in Temporal. With only one workflow task slot only one poll is ever in flight, and the sticky balancer always assigns it to the sticky queue, leaving new workflows stranded on the normal queue for a full 60s long poll.
lschim
force-pushed
the
refactor/split-workflow-registration
branch
from
August 14, 2026 16:20
3fee0c8 to
2844b7b
Compare
lschim
marked this pull request as ready for review
August 14, 2026 16:26
Contributor
|
LGTM ! |
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.
Why
The discovery of Workflows was hardcoded on detecting single activity workflows annotated with @WorkflowInterface, the PR offers a way to register different types of Workflows.
Also,
TemporalInterlocutorcarried three responsibilities: talking to Temporal, knowing the naming convention that maps a workflow interface to its implementation and activity, and owning the lifecycle of the workers serving them. This PR extracts the last two; the interlocutor is a Temporal client again.It is also the occasion to widen the possibilities of queue management and ease of starting workers.
The two extracted classes
WorkflowRegistry: what should be served, and on which queue. Manual registration, discovery by naming convention, read views. No Temporal dependency at all, no client.TemporalWorkers.start(client, registry, listeningQueues, options)— starts the workers and returns theCloseable. The only part that knows aboutWorkerFactory.The substantive change: when the routing decision is made
Discovery used to drop every workflow that did not belong to the worker's group (
makeWorkflowFilter(routingStrategy, group)), so a process could only ever serve one queue.The registry now registers everything it finds, keyed by the queue the routing strategy resolves, and
TemporalWorkers.startpicks which of those queues to poll. A distributed deployment can serve a subset;CommonModeserves everything it discovered. This is what unblocks the fan-out.