Repository navigation
fix(id): always compare legacy IDs below newly formatted IDs - #778
Merged
behinddwalls merged 1 commit intoOct 6, 2026
Merged
Conversation
mnoah1
added this pull request to stack #771
October 5, 2026 20:36
mnoah1
requested review from
a team,
behinddwalls and
sbalabanov
as code owners
October 5, 2026 20:36
mnoah1
changed the title
mnoah1
force-pushed
the
mnoah1/id-migration-compat
branch
from
October 5, 2026 20:56
e7048c0 to
4f98510
Compare
behinddwalls
approved these changes
Oct 5, 2026
behinddwalls
force-pushed
the
mnoah1/id-migration-compat
branch
from
October 5, 2026 23:21
4f98510 to
38c6495
Compare
behinddwalls
force-pushed
the
mnoah1/id-migration-compat
branch
from
October 5, 2026 23:40
38c6495 to
96f17ad
Compare
This was referenced Oct 5, 2026
behinddwalls
temporarily deployed
to
stack-rebase
October 6, 2026 17:10 — with 
GitHub Actions
Inactive
GitHub Actions
Inactive
Tmwakalasya
pushed a commit
to Tmwakalasya/submitqueue
that referenced
this pull request
Oct 6, 2026
## Summary ### Why? Resource identity should stay flexible at storage and API boundaries even when the current allocator produces sequential numbers. ### What? Define generated IDs as canonical decimal strings, keep resource and reference columns as VARCHAR, and limit integer storage to counter high-water marks. Replace the URLs and display examples with a before/after table showing base64url, percent-encoded, and readable queue-scoped routes; leave the rest of the proposal intact. ## Stack 1. @ uber#762 1. uber#770 1. uber#778
Tmwakalasya
pushed a commit
to Tmwakalasya/submitqueue
that referenced
this pull request
Oct 6, 2026
## Summary ### Why? Queue-prefixed resource IDs contain URL separators and duplicate scope already carried by the queue, route, and typed field. Resource IDs should remain flexible string contracts rather than forcing Go, protobuf, or SQL resource fields to integer types. ### What? - Store canonical positive decimal strings such as "42" for SubmitQueue request IDs, SubmitQueue batch IDs, and Stovepipe request IDs while keeping resource and reference fields as strings and VARCHAR columns. - Keep the existing counter schema and (queue, domain) key unchanged; domain names the sequence (request or batch), not an application. SubmitQueue and Stovepipe have separate storage backends, so no ownerDomain dimension is introduced. Stovepipe uses the durable MySQL counter. - Put the shared formatting, validation, and numeric comparison helpers in platform/base/id. Keep domain naming consistent across the counter contract, implementation, callers, mocks, tests, and docs. - Validate direct resource-ID inputs and retain the queue-scoped test fixes and cross-queue ID regression coverage from the prior review pass. Provider IDs, URIs, hashes, and derived event IDs keep their contracts. ## Test Plan - ✅ make build - ✅ Latest stack validation: make test (130 targets passed) - ✅ make check-gazelle, make check-mocks, make check-tidy, and make lint - ✅ git diff --check - ✅ git diff --quiet main -- ':(glob)**/schema/*.sql' (no schema differences from main) - ✅ Rebased onto main (`5b6af68f`), preserving the RFC → implementation stack and all seven commits. Runtime code is unchanged by the RFC table update. - ✅ Fresh MySQL counter integration run with test-result caching disabled. - ✅ The preceding comment pass also ran SubmitQueue gateway integration, Stovepipe integration, and Stovepipe e2e successfully (4/4 targets including the counter suite). -⚠️ aifx verify could not complete its monorepo coverage, generic Go lint, and UReview API checks; repository-native checks above passed. ## Stack 1. uber#762 1. @ uber#770 1. uber#778
This branch was previously deployed
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.
Update stovepipe's ID comparisons - place all legacy requests before the new numerical only value. This will avoid existing queues getting wedged when they hit the boundary between the last legacy request, and first new one.
Why?
Without this change, queues would have stalled at the boundary between the last legacy request bookmark, and the next incoming request in the new format. The comparison would have continually failed, and never drained out, because we are trying to compare a request in the old format, with a request in the new format.
What?
Adjust the request ID comparator to place all legacy requests before new ones in ordering.
Within each format, IDs retain numeric ordering. Decimal IDs sort after all valid legacy IDs; this assumes a one-way writer switch from legacy to decimal IDs.
Test Plan
5b6af68f), preserving all eight commits and the compatibility patch's five-file scope.Stack