Skip to content

fix(id): always compare legacy IDs below newly formatted IDs - #778

Merged
behinddwalls merged 1 commit into
preetam/numeric-resource-idsfrom
mnoah1/id-migration-compat
Oct 6, 2026
Merged

behinddwalls merged 1 commit into
preetam/numeric-resource-idsfrom
mnoah1/id-migration-compat

Conversation

@mnoah1

@mnoah1 mnoah1 commented Oct 5, 2026 •

Copy link
Copy Markdown
Contributor

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. docs: define scoped sequential resource IDs #762
  2. feat(ids): use queue-scoped decimal resource IDs #770
  3. @ fix(id): always compare legacy IDs below newly formatted IDs #778

@mnoah1
mnoah1 added this pull request to stack #771 October 5, 2026 20:36
@mnoah1
mnoah1 requested review from a team, behinddwalls and sbalabanov as code owners October 5, 2026 20:36
@mnoah1 mnoah1 changed the title fix(id): preserve legacy IDs across decimal migration fix(id): always compare legacy IDs below newly formatted IDs Oct 5, 2026
@mnoah1
mnoah1 force-pushed the mnoah1/id-migration-compat branch from e7048c0 to 4f98510 Compare October 5, 2026 20:56
@behinddwalls
behinddwalls force-pushed the mnoah1/id-migration-compat branch from 4f98510 to 38c6495 Compare October 5, 2026 23:21
@behinddwalls
behinddwalls force-pushed the mnoah1/id-migration-compat branch from 38c6495 to 96f17ad Compare October 5, 2026 23:40
@behinddwalls
behinddwalls added this pull request to the merge queue Oct 6, 2026
Merged via the queue into main with commit e6e5251 Oct 6, 2026
16 of 29 checks passed
@behinddwalls
behinddwalls deployed to stack-rebase October 6, 2026 17:10 — with GitHub Actions Active
@behinddwalls
behinddwalls deleted the mnoah1/id-migration-compat branch October 6, 2026 17:11
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 successfully deployed

1 active deployment
stack-rebase — 96f17adb Deployed Oct 6, 2026 by behinddwalls via Rebase Stack #561
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