Repository navigation
docs: define scoped sequential resource IDs - #762
Merged
Merged
Conversation
behinddwalls
marked this pull request as ready for review
September 30, 2026 22:09
mnoah1
reviewed
Oct 1, 2026
behinddwalls
force-pushed
the
preetam/id-uri-rfc
branch
from
October 2, 2026 19:58
d08a8da to
343875c
Compare
behinddwalls
added this pull request to stack #771
October 2, 2026 20:48
behinddwalls
force-pushed
the
preetam/id-uri-rfc
branch
from
October 2, 2026 22:41
343875c to
d16ebc4
Compare
mnoah1
approved these changes
Oct 5, 2026
behinddwalls
force-pushed
the
preetam/id-uri-rfc
branch
from
October 5, 2026 19:05
d16ebc4 to
fcef650
Compare
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Oct 5, 2026
behinddwalls
force-pushed
the
preetam/id-uri-rfc
branch
2 times, most recently
from
October 5, 2026 23:21
d9fb34b to
c54b882
Compare
## Summary ### Why? Slash-delimited resource IDs repeat queue and resource-kind context that stores, APIs, and messages already carry separately, while making a single ID span multiple browser path segments. ### What? Define counter-generated resource IDs as positive numeric values scoped by owner domain, queue, and resource kind. Persist durable counter high-water marks, store numeric IDs directly under queue-leading keys, keep queue and kind out of the ID, and reserve prefixes such as `request.42` for presentation only. ## Test Plan ✅ `make fmt` ✅ `make lint-binary lint-license lint-message-id lint-queue-shard` ✅ `git diff --check`
## 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.
## 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.
behinddwalls
force-pushed
the
preetam/id-uri-rfc
branch
from
October 5, 2026 23:40
c54b882 to
e6bfaa0
Compare
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
Tmwakalasya
pushed a commit
to Tmwakalasya/submitqueue
that referenced
this pull request
Oct 6, 2026
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 - Updated tests - During deployment, monitor that new requests continue to advance beyond the last legacy-formatted request. - ✅ Rebased the RFC → ID implementation → compatibility stack onto main (`5b6af68f`), preserving all eight commits and the compatibility patch's five-file scope. - ✅ make lint, make check-gazelle, make check-mocks, make check-tidy, make build, and make test (130 targets passed) - ✅ git diff --check -⚠️ 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 successfully 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.
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