Skip to content

feat(stovepipe): look up current and commit-specific queue status - #857

Open
mnoah1 wants to merge 5 commits into
mainfrom
mnoah1/stovepipe-queue-state-lookup
Open

mnoah1 wants to merge 5 commits into
mainfrom
mnoah1/stovepipe-queue-state-lookup

Conversation

@mnoah1

@mnoah1 mnoah1 commented Oct 14, 2026 •

Copy link
Copy Markdown
Contributor

Why?

Clients need the enablement occurrence covering a commit, including intermediate commits without a validation request.

What?

Implement GetQueueStatus using a pinned summary and retained history. Return the selected enablement and its commit boundary, version and timestamp together in QueueEnablementStatus. Omit change_uri for the latest materialized state, or supply it to select the newest inclusive covering boundary. Resolve ancestry through the existing source-control extension and reject incomparable commits. Add transport mapping, service wiring and endpoint tests; lookup never repairs or changes stored state.

Test Plan

All 27 Stovepipe/service unit, MySQL integration, service integration and end-to-end targets passed. Coverage includes intermediate commits, equal boundaries, incomparable merged-branch commits, pinned reads and dependency failures. Run make local-stovepipe-start, then call GetQueueStatus with a configured queue; omit change_uri for current state or supply an immutable commit URI. No enablement administration or execution gating is included.

Revert Plan

Revert this layer to leave GetQueueStatus unimplemented while preserving the state and read models.

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
  2. Storage
  3. Transitions and materialization
  4. Lookup (this PR)

@mnoah1
mnoah1 added this pull request to stack #858 October 14, 2026 15:45
@mnoah1
mnoah1 force-pushed the mnoah1/stovepipe-queue-state-lookup branch from d0fa4b0 to 91f1b34 Compare October 14, 2026 15:56
@mnoah1
mnoah1 force-pushed the mnoah1/stovepipe-queue-state-lookup branch from 91f1b34 to 780b8a4 Compare October 14, 2026 17:27
@mnoah1
mnoah1 force-pushed the mnoah1/stovepipe-queue-state-lookup branch from 780b8a4 to 8c35f52 Compare October 14, 2026 17:43
@mnoah1
mnoah1 force-pushed the mnoah1/stovepipe-queue-state-lookup branch from 8c35f52 to 1f58db9 Compare October 14, 2026 17:51

@behinddwalls behinddwalls left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The walk back through history, the error classification (source-control not-found and non-ancestor are user errors, everything else stays infra), and the no-repair read path all look right. One suggestion on the e2e test structure.

Comment thread test/e2e/stovepipe/queue_status_test.go
Comment thread service/stovepipe/README.md
@mnoah1
mnoah1 force-pushed the mnoah1/stovepipe-queue-state-lookup branch 2 times, most recently from 11b396a to 2251dc3 Compare October 14, 2026 22:35
@mnoah1
mnoah1 force-pushed the mnoah1/stovepipe-queue-state-lookup branch 2 times, most recently from 12c904b to 2dc36fa Compare October 14, 2026 23:29
@mnoah1
mnoah1 marked this pull request as ready for review October 14, 2026 23:43
@mnoah1
mnoah1 requested review from a team and sbalabanov as code owners October 14, 2026 23:43
@mnoah1 mnoah1 changed the title feat(stovepipe): [DRAFT] look up current and commit-specific queue status feat(stovepipe): look up current and commit-specific queue status Oct 14, 2026
@mnoah1
mnoah1 force-pushed the mnoah1/stovepipe-queue-state-lookup branch from 8764f68 to 8110a41 Compare October 16, 2026 14:26
@mnoah1
mnoah1 force-pushed the mnoah1/stovepipe-queue-state-lookup branch from 8110a41 to 5c07651 Compare October 16, 2026 17:24
@mnoah1
mnoah1 added this pull request to the merge queue Oct 16, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Oct 16, 2026
Base automatically changed from mnoah1/stovepipe-queue-state-transitions to main October 16, 2026 17:43
…atus

Summary:
Clients need the enablement occurrence covering a commit, including intermediate commits without a validation request.

Implement GetQueueStatus using a pinned summary and retained history. Omit change_uri for the latest materialized state, or supply it to select the newest inclusive covering boundary. Resolve ancestry through the existing source-control extension and reject incomparable commits. Add transport mapping, service wiring and endpoint tests; lookup never repairs or changes stored state.

Part 4 of 4, built on transitions and materialization. The read model can lag an interrupted internal write until the writer retries.

Test Plan:
All 27 Stovepipe/service unit, MySQL integration, service integration and end-to-end targets passed. Coverage includes intermediate commits, equal boundaries, incomparable merged-branch commits, pinned reads and dependency failures. Run make local-stovepipe-start, then call GetQueueStatus with a configured queue; omit change_uri for current state or supply an immutable commit URI. No enablement administration or execution gating is included.
Run transition and RPC error cases as named subtests, with error cases in their own suite test. Give the service README queue status paragraph a separate heading.
@mnoah1
mnoah1 force-pushed the mnoah1/stovepipe-queue-state-lookup branch from 5c07651 to f0ee7a0 Compare October 16, 2026 17:43
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
## 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.

1. [API and RFC](uber#854)
2. [Storage](uber#855) (this PR)
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 branch has not been deployed

No deployments
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