You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(orchestrator): carry the queue explicitly on every internal payload (#527)
## Summary
### Why?
Consumers today learn a message's queue only by loading the referenced
entity from storage, and entity IDs are opaque — nothing may parse a
queue out of an ID prefix. For storage to become queue-scoped (resolved
per queue like every other extension), every consumer must hold the
queue before its first storage read, so the queue has to ride on the
wire explicitly.
### What?
The internal payload types (`RequestID`, `BatchID`, `BuildID`,
`CancelRequest`) gain a `queue` field; the change is additive JSON, and
payloads written before the field existed decode with an empty queue.
Publishers stamp it from the entity they already hold: start,
mergeconflictsignal, batch, speculate, mergesignal, build, buildsignal,
and the orchestrator cancel controller; the gateway cancel controller
stamps the authoritative queue from the stored request summary,
overriding caller input. Consumers guard that a non-empty payload queue
matches the loaded entity's queue and reject mismatches as malformed
(non-retryable, straight to DLQ) — the guard becomes the routing input
once storage is queue-resolved. Buildsignal's re-publish to speculate
now partitions by the batch's queue instead of the inherited batch-ID
partition key, matching every other speculate publisher and restoring
the per-queue serial-processing guarantee that stage relies on.
## Test Plan
✅ `go test ./...` ✅ `make fmt` ✅ `make lint` — new unit tests cover the
queue stamp on published payloads and the mismatch rejection guard.
0 commit comments