Repository navigation
Conversation
This was referenced Oct 14, 2026
mnoah1
added this pull request to stack #858
October 14, 2026 15:45
mnoah1
force-pushed
the
mnoah1/stovepipe-queue-state-storage
branch
4 times, most recently
from
October 14, 2026 17:51
7271e36 to
b3aa4af
Compare
behinddwalls
left a comment
behinddwalls
left a comment
Collaborator
There was a problem hiding this comment.
Stores and schema look clean. They're key-only, have no secondary indexes, and queue leads the primary keys. One question about rollout, and one housekeeping item.
mnoah1
force-pushed
the
mnoah1/stovepipe-queue-state-storage
branch
3 times, most recently
from
October 14, 2026 22:49
703bd88 to
f5c6597
Compare
Contributor
Author
Were there meant to be some inline comments for these? |
mnoah1
marked this pull request as ready for review
October 14, 2026 23:07
mnoah1
changed the title
mnoah1
force-pushed
the
mnoah1/stovepipe-queue-state-storage
branch
from
October 16, 2026 14:26
f5c6597 to
df1f9a2
Compare
behinddwalls
approved these changes
Oct 16, 2026
Summary: Queue enablement needs durable internal state and separate read models so orchestration updates do not alter enablement history. Extend the existing queue snapshot, add immutable QueueLog and derived QueueSummary records, and implement key-oriented stores with conditional writes. Include the one-time migration for existing queue tables and backend tests for byte-exact queue identity and independent projection versions. Part 2 of 4, built on the API and RFC. This layer supplies storage for transitions and lookup. Test Plan: Run the Stovepipe storage unit and MySQL integration tests. Migration coverage verifies existing operational values survive. Before deploying to an existing database, apply queue_enablement.sql once and create the queue log and summary tables.
mnoah1
force-pushed
the
mnoah1/stovepipe-queue-state-storage
branch
from
October 16, 2026 17:25
df1f9a2 to
91d2c33
Compare
DivyanshGarg380
pushed a commit
to DivyanshGarg380/submitqueue
that referenced
this pull request
Oct 17, 2026
## Why? Queue enablement needs a dedicated lookup: validation results and the current queue row do not identify the state covering an arbitrary commit. ## What? Define GetQueueStatus with an optional change URI and an `enablement` field of type `QueueEnablementStatus`, commit generated bindings, and document inclusive boundaries, intermediate commits and error semantics in the indexed RFC. The RPC remains unimplemented until the final layer. ## Test Plan Build the published bindings and run the Stovepipe server tests. The final stack also passes all 27 Stovepipe unit, MySQL integration, service integration and end-to-end targets. ## Revert Plan Revert this layer together with any dependent layers in the stack. ## Stack Review in this order; each PR targets the preceding branch. 1. [API and RFC](uber#854) (this PR) 2. [Storage](uber#855) 3. [Transitions and materialization](uber#856) 4. [Lookup](uber#857)
DivyanshGarg380
pushed a commit
to DivyanshGarg380/submitqueue
that referenced
this pull request
Oct 17, 2026
…r#856) ## Why? Queue enablement changes must preserve coordination fields and remain recoverable when history or summary writes fail. ## What? Add an internal TransitionController with Initialize, Prepare and Apply, plus queuelog.Materializer.PersistLog. Retain the previous occurrence before replacing internal enablement and materialize the committed winner afterward. Prepared retries preserve the accepted boundary; optimistic locking handles operational races. Startup registers configured queues as disabled without overwriting registered enablement. ## Test Plan Unit, service integration and end-to-end tests cover competing decisions, operational races, projection races and failed writes. Run make local-stovepipe-start for local startup with schemas applied before registration. Changing enablement uses the internal transition controller; this layer adds no mutation RPC or CLI. ## Revert Plan Revert this layer together with any dependent layers in the stack. ## Issue Links None — this is a standalone queue-status proposal. ## Stack Review in this order; each PR targets the preceding branch. 1. [API and RFC](uber#854) 2. [Storage](uber#855) 3. [Transitions and materialization](uber#856) (this PR) 4. [Lookup](uber#857)
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.
Why?
Queue enablement needs durable internal state and separate read models so orchestration updates do not alter enablement history.
What?
Extend the existing queue snapshot, add immutable QueueLog and derived QueueSummary records, and implement key-oriented stores with conditional writes. Add queue and read-model schemas, with backend tests for byte-exact queue identity and independent projection versions.
Test Plan
Run the Stovepipe storage unit and MySQL integration tests.
Revert Plan
Revert this layer together with any dependent layers in the stack.
Issue Links
None — this is a standalone queue-status proposal.
Stack
Review in this order; each PR targets the preceding branch.