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
refactor(messagequeue): make publish tenant explicit
## Summary
### Why?
Tenant selects the physical MQ shard and is therefore a first-class publish input, not metadata to infer implicitly. Parsing MQ_TENANTS is service wiring behavior rather than a responsibility of the MySQL backend.
### What?
- Require tenant explicitly in platform publish and hook APIs, propagate it to queue_name metadata, and reject conflicting metadata.
- Pass each producer's authoritative queue through SubmitQueue, Runway, Stovepipe, hooks, and tests independently from partition keys.
- Move required-tenant parsing into a shared service/messagequeue wiring package.
## Test Plan
✅ Focused unit tests across publish, hook, service wiring, Runway, Stovepipe, and SubmitQueue controllers
✅ `./tool/bazel build //...`
✅ `make fmt && make gazelle`
Co-authored-by: Cursor <cursoragent@cursor.com>
Copy file name to clipboardExpand all lines: doc/rfc/messagequeue-tenant-sharding.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -76,7 +76,7 @@ Fair-share, orphan sweep, and idle-lease release run per `(tenant, topic)`, not
76
76
77
77
## Publish
78
78
79
-
`platform/publish` stamps `Message.Tenant`from context metadata (`queue_name`). Empty tenant on publish is rejected. `PartitionKey` is unchanged.
79
+
Every `platform/publish`call supplies tenant explicitly. The package stamps `Message.Tenant`and mirrors it into `queue_name` delivery metadata, rejecting empty tenants and conflicting caller metadata. `PartitionKey` is unchanged.
0 commit comments