Skip to content

[2/2 messagequeue] Add Vitess vschema and two-shard vtcombo suite - #696

Merged
behinddwalls merged 1 commit into
mainfrom
preetam/mq-tenant-vitess
Sep 10, 2026
Merged

[2/2 messagequeue] Add Vitess vschema and two-shard vtcombo suite#696
behinddwalls merged 1 commit into
mainfrom
preetam/mq-tenant-vitess

Conversation

@behinddwalls

@behinddwalls behinddwalls commented Sep 8, 2026

Copy link
Copy Markdown
Collaborator

Summary

Why?

The tenant column is the production vindex. Without a VSchema and a two-shard suite, the schema change is unproven on Vitess.

What?

  • Add production xxhash VSchema for every queue table keyed on tenant.
  • Add a vtcombo integration suite that publishes and consumes across two shards (receive loop bound to the test context).

Admin CLI tenant flags shipped with the schema PR because ctl/lib SQL is coupled to the new primary keys.

Test Plan

Vitess suite is Docker-based; run with:
./tool/bazel test //test/integration/extension/messagequeue/mysql/vitess:go_default_test --strategy=TestRunner=local

Co-authored-by: Cursor cursoragent@cursor.com

@behinddwalls
behinddwalls force-pushed the preetam/mq-tenant-vitess branch from 0b69e19 to 4980b66 Compare September 10, 2026 18:57
@behinddwalls behinddwalls changed the title [4/4 messagequeue] Add Vitess vschema and two-shard vtcombo suite [3/3 messagequeue] Add Vitess vschema and two-shard vtcombo suite Sep 10, 2026
behinddwalls added a commit that referenced this pull request Sep 10, 2026
## Summary

### Why?

Vitess needs a stable vindex that is not the Kafka-style partition key.
Isolation has to be an explicit tenant column, with identity carried on
publish and consume so two tenants sharing a partition key cannot
collide.

### What?

- Prefix every queue table and store query with tenant; set
queue_offsets PK to (tenant, topic, partition_key, consumer_group).
- Use typed (tenant, partitionKey) identities in consumers, gates, and
MySQL workers; stop workers when lease discovery cannot confirm
ownership.
- Require tenant on publish.Message and validate payload queue against
message tenant in pipeline controllers (the publish signature change is
not compilable without those call sites).
- Add ParseRequiredTenants and wire Stovepipe ingest to the configured
tenant list so NewIngestController still builds.
- Require tenant xor all-tenants on MQ admin list commands; message
inspect/delete/requeue take the full (tenant, topic, partition, id)
identity.
- Comment ascii/ascii_bin vs utf8mb4/utf8mb4_bin on every queue table,
with the full encoding note on queue_messages.

## Test Plan

✅ `go test` on mysql, publish, consumer, messagequeue identity,
service/messagequeue, and start controller

Rebased onto current `main` after RFC #693 merged.

## Stack

- ~~[#693](#693) RFC: per-tenant
sharding for the MySQL message queue~~ (merged)
- [#694](#694) Shard MySQL
queues by tenant identity
- [#695](#695) Wire MQ_TENANTS
through services and tests
- [#696](#696) Add Vitess
vschema and two-shard vtcombo suite

---------

Co-authored-by: Cursor <cursoragent@cursor.com>
@behinddwalls
behinddwalls force-pushed the preetam/mq-tenant-vitess branch from 4980b66 to 59b20cb Compare September 10, 2026 19:51
@behinddwalls behinddwalls changed the title [3/3 messagequeue] Add Vitess vschema and two-shard vtcombo suite [2/2 messagequeue] Add Vitess vschema and two-shard vtcombo suite Sep 10, 2026
behinddwalls added a commit that referenced this pull request Sep 10, 2026
## Summary

### Why?

The MySQL subscriber only discovers partitions for configured tenants.
Service processes and compose stacks must pass the same list they
already use as queue names, or Subscribe fails at startup and tests talk
to an unsharded process.

### What?

- Parse MQ_TENANTS in gateway, orchestrator, and runway wiring and
reject configs whose queue names do not match.
- Set MQ_TENANTS in service compose files, e2e harnesses, and
SubmitQueue integration suites.

## Test Plan

✅ `go test` TestValidateConfiguredQueueTenants,
TestValidateProfileQueueTenants, TestValidateMergeQueueTenants, and
service/messagequeue

Rebased onto current `main` after #694 merged.

## Stack

- ~~[#693](#693) RFC: per-tenant
sharding for the MySQL message queue~~ (merged)
- ~~[#694](#694) Shard MySQL
queues by tenant identity~~ (merged)
- [#695](#695) Wire MQ_TENANTS
through services and tests
- [#696](#696) Add Vitess
vschema and two-shard vtcombo suite

Co-authored-by: Cursor <cursoragent@cursor.com>
Base automatically changed from preetam/mq-tenant-wiring to main September 10, 2026 19:59
behinddwalls added a commit that referenced this pull request Sep 10, 2026
## Summary

### Why?

The MySQL subscriber only discovers partitions for configured tenants.
Service processes and compose stacks must pass the same list they
already use as queue names, or Subscribe fails at startup and tests talk
to an unsharded process.

### What?

- Parse MQ_TENANTS in gateway, orchestrator, and runway wiring and
reject configs whose queue names do not match.
- Set MQ_TENANTS in service compose files, e2e harnesses, and
SubmitQueue integration suites.

## Test Plan

✅ `go test` TestValidateConfiguredQueueTenants,
TestValidateProfileQueueTenants, TestValidateMergeQueueTenants, and
service/messagequeue

Rebased onto current `main` after #694 merged.

## Stack

- ~~[#693](#693) RFC: per-tenant
sharding for the MySQL message queue~~ (merged)
- ~~[#694](#694) Shard MySQL
queues by tenant identity~~ (merged)
- [#695](#695) Wire MQ_TENANTS
through services and tests
- [#696](#696) Add Vitess
vschema and two-shard vtcombo suite

Co-authored-by: Cursor <cursoragent@cursor.com>
@behinddwalls
behinddwalls force-pushed the preetam/mq-tenant-vitess branch from 59b20cb to 13addff Compare September 10, 2026 19:59
## Summary

### Why?

The tenant column is the production vindex. Without a VSchema and a two-shard suite, the schema change is unproven on Vitess.

### What?

- Add production xxhash VSchema for every queue table keyed on tenant.
- Add a vtcombo integration suite that publishes and consumes across two shards (receive loop bound to the test context).

Admin CLI tenant flags shipped with the schema PR because ctl/lib SQL is coupled to the new primary keys.

## Test Plan

Vitess suite is Docker-based; run with:
`./tool/bazel test //test/integration/extension/messagequeue/mysql/vitess:go_default_test --strategy=TestRunner=local`

Co-authored-by: Cursor <cursoragent@cursor.com>
@behinddwalls
behinddwalls force-pushed the preetam/mq-tenant-vitess branch from 13addff to a225fd4 Compare September 10, 2026 20:08
@behinddwalls behinddwalls changed the title [2/2 messagequeue] Add Vitess vschema and two-shard vtcombo suite [1/1 messagequeue] Add Vitess vschema and two-shard vtcombo suite Sep 10, 2026
@behinddwalls behinddwalls changed the title [1/1 messagequeue] Add Vitess vschema and two-shard vtcombo suite Scale tenant reconciliation for sharded queues Sep 10, 2026
@behinddwalls
behinddwalls force-pushed the preetam/mq-tenant-vitess branch from ab68ac3 to a225fd4 Compare September 10, 2026 21:00
@behinddwalls behinddwalls changed the title Scale tenant reconciliation for sharded queues [2/2 messagequeue] Add Vitess vschema and two-shard vtcombo suite Sep 10, 2026
@behinddwalls
behinddwalls merged commit c4cd74e into main Sep 10, 2026
21 of 27 checks passed
@behinddwalls
behinddwalls deleted the preetam/mq-tenant-vitess branch September 10, 2026 21:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants