Modularize orchestrator wiring: extract queue profiles, topic registry builder, and controller registration#290
Open
JamyDev wants to merge 2 commits into
Open
Modularize orchestrator wiring: extract queue profiles, topic registry builder, and controller registration#290JamyDev wants to merge 2 commits into
JamyDev wants to merge 2 commits into
Conversation
Propose extracting per-queue extension profiles, topic-registry builder, and controller registration from the orchestrator example main.go into reusable domain packages, plus data-driven profile hints in QueueConfig. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
JamyDev
changed the title
JamyDev
commented
Jun 30, 2026
|
|
||
| This keeps the controller list in the domain layer (testable, importable) and reduces the wiring main.go to: build dependencies → call `wire.RegisterPrimary` → call `wire.RegisterDLQ`. Adding a new pipeline stage becomes a single-file edit in this package. | ||
|
|
||
| ### 4. Extend `QueueConfig` with optional profile hints |
Contributor
Author
There was a problem hiding this comment.
This may be a bit controversial @behinddwalls :)
JamyDev
requested review from
a team,
behinddwalls and
sbalabanov
as code owners
…onfig removal Analyze three options for per-queue extension selection in light of potential QueueConfig removal: hints in the entity, a separate profile config file, or keeping profiles in Go code only. Recommends landing the mechanical extractions (steps 1-3) unconditionally and deferring step 4 until the QueueConfig question is resolved. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
JamyDev
force-pushed
the
jamy/rfc-modular-queue-wiring
branch
from
8801dd0 to
3d8d47f
Compare
JamyDev
commented
Jul 13, 2026
| |---|---|---|---| | ||
| | **A: Profile hints in QueueConfig (step 4 as proposed)** | Add `QueueProfile` fields to the entity; deployers declare scorer/conflict/etc. in `queues.yaml`; the wiring layer maps hint strings → instances. | Single source of truth for queue identity + behavior. YAML-only queue addition for known extension types. | Expands `QueueConfig` from a pure name registry into a config carrier — if QueueConfig is later removed, these fields need a new home. The entity gains fields the gateway doesn't use (profile hints are orchestrator-only). | | ||
| | **B: Separate profile config file** | Leave `QueueConfig` as-is (name-only). Create a separate `queue-profiles.yaml` (or a `profiles:` section in a new file) consumed only by the orchestrator wiring. The orchestrator loads both queue names and profiles; the gateway loads only names. | Clean separation: gateway validates names, orchestrator resolves profiles. `QueueConfig` stays minimal and removable. No entity-level coupling. | Two config files to keep in sync (queue names must match). More moving parts in the wiring layer. | | ||
| | **C: No data-driven profiles — keep profiles in Go code** | Drop step 4 entirely. Steps 1–3 (queueprofile, topicregistry, wire) still land as mechanical extractions. Per-queue profiles stay in Go, just using the promoted `queueprofile.Registry` instead of the current inline types. | Simplest change. No new config surface. Full type safety — a misspelled scorer name is a compile error, not a runtime lookup miss. Consistent with the existing philosophy ("all behavioral and VCS configuration lives in the extension factory implementations"). | Adding a new queue still requires a recompile. Doesn't address the "three-place edit" problem for deployers who don't write custom extensions. | |
Contributor
Author
There was a problem hiding this comment.
Think I'm leaning option C here @behinddwalls
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
1 participant
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.
Summary
Adds an RFC at doc/rfc/submitqueue/modular-queue-wiring.md proposing 5 extractions to make the orchestrator's queue setup more modular:
Also adds the RFC to doc/rfc/index.md. Doc-only change, no code modifications.
Test Plan
CI/Build validation
Revert Plan
git revert
API Changes
No API changes
Monitoring and Alerts
Standard monitoring via existing dashboards
🤖 Generated by minion
Co-Authored-By: minion-bot noreply@minion.uber.com
Co-Authored-By: jamy@uber.com
Agent: claude-code | Task: b069bea1-12a5-478a-b517-61ce0abd6749
View your task: https://minion.uberinternal.com/task/b069bea1-12a5-478a-b517-61ce0abd6749
AI Verification
0 issues detected
Skipped verifiers: uber-one, web, diff-template, java-lint, go-lint, go-coverage, go-glint, go-proto-lint, go-thrift-lint, android-lint, java-coverage, ios-lint, android-coverage, ios-test, claude · EngWiki
Prior runs
Run at
fcb7447on Jun 30 15:50 · 2 files · 1s · 0 issues detectedIssues