feat(stovepipe): add request and request-log entity stores#269
Closed
behinddwalls wants to merge 2 commits into
Closed
feat(stovepipe): add request and request-log entity stores#269behinddwalls wants to merge 2 commits into
behinddwalls wants to merge 2 commits into
Conversation
## Summary ### Why? Stovepipe promotes an already-verified commit onto a verified branch (e.g. `verified/main`) as-is. The existing `REBASE`/`SQUASH_REBASE`/`MERGE` strategies cannot express this — they all transform the change and produce new revisions. We need a shared, VCS-neutral way for a client to ask Runway to advance a branch to an already-existing commit. ### What? Adds `PROMOTE` (= 4) to the shared `Strategy` enum in `api/base/mergestrategy` and the matching `MergeStrategyPromote` Go entity constant in `platform/base/mergestrategy`. `PROMOTE` means "integrate the exact revision as-is, with no content transform": each backend realizes it natively (git fast-forward, Mercurial bookmark advance, Subversion/Perforce copy), so a step's output revision is the same commit the request named rather than a freshly created one. The Runway merge-queue contract README gains a "Merge strategy" section documenting the semantics. This is contract + docs only — no producer or consumer wiring is added yet. ## Test Plan ✅ `make proto` (regenerated `api/base/mergestrategy/protopb`) ✅ `bazel build //api/base/mergestrategy/protopb //platform/base/mergestrategy` Co-authored-by: Cursor <cursoragent@cursor.com>
## Summary
### Why?
Stovepipe needs a persistence layer to track trunk-validation requests, mirroring SubmitQueue's two-store split by service ownership. Until now Stovepipe only had the `IngestRequest` queue payload and no entity stores, so the orchestrator forwarded full payloads and nothing recorded request state or customer-facing status.
### What?
Adds the foundational entities and storage interfaces (plus a MySQL implementation and mocks), mirroring the SubmitQueue pattern. Identity stays the synthetic SPID (`{queue}/{counter}`) and everything is modeled as request + change + URIs — there is no SHA/commit entity.
- `stovepipe/entity`: `Request` (orchestrator-owned state machine with `State`/`Version`), the `RequestState` enum, a thin `RequestID` queue payload, and an append-only `RequestLog` with a customer-facing `RequestStatus`. The existing `IngestRequest` stays as the gateway-to-orchestrator payload.
- `stovepipe/extension/storage`: a `Storage` factory plus `RequestStore` (orchestrator-owned) and `RequestLogStore` (gateway-owned) interfaces, shared error sentinels, and `//go:generate` mockgen directives.
- `stovepipe/extension/storage/mysql`: a MySQL-backed implementation with optimistic-locking conditional writes and `request` / `request_log` schemas.
- `stovepipe/extension/storage/mock`: generated gomock mocks; the Makefile `mocks` target now includes the Stovepipe storage path.
Wiring the stores into controllers and example servers is a deliberate follow-up.
This also includes the regenerated `api/submitqueue/gateway/protopb/gateway.pb.yarpc.go` descriptor closure — a leftover regeneration from the already-merged PROMOTE merge-strategy change, since the gateway yarpc file embeds the transitive mergestrategy descriptor.
## Test Plan
- `bazel test //stovepipe/...` — all targets pass
- `make fmt`, `make lint-license`, `make gazelle` — clean / idempotent
- `make proto` reproduces the committed descriptors
Collaborator
Author
|
Duplicate of #267, which is already merged into main (same branch |
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
1 participant
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
Summary
Why?
Stovepipe needs a persistence layer to track trunk-validation requests, mirroring SubmitQueue's two-store split by service ownership. Until now Stovepipe only had the
IngestRequestqueue payload and no entity stores, so the orchestrator forwarded full payloads and nothing recorded request state or customer-facing status.What?
Adds the foundational entities and storage interfaces (plus a MySQL implementation and mocks), mirroring the SubmitQueue pattern. Identity stays the synthetic SPID (
{queue}/{counter}) and everything is modeled as request + change + URIs — there is no SHA/commit entity.stovepipe/entity:Request(orchestrator-owned state machine withState/Version), theRequestStateenum, a thinRequestIDqueue payload, and an append-onlyRequestLogwith a customer-facingRequestStatus. The existingIngestRequeststays as the gateway-to-orchestrator payload.stovepipe/extension/storage: aStoragefactory plusRequestStore(orchestrator-owned) andRequestLogStore(gateway-owned) interfaces, shared error sentinels, and//go:generatemockgen directives.stovepipe/extension/storage/mysql: a MySQL-backed implementation with optimistic-locking conditional writes andrequest/request_logschemas.stovepipe/extension/storage/mock: generated gomock mocks; the Makefilemockstarget now includes the Stovepipe storage path.Wiring the stores into controllers and example servers is a deliberate follow-up.
This also includes the regenerated
api/submitqueue/gateway/protopb/gateway.pb.yarpc.godescriptor closure — a leftover regeneration from the already-merged PROMOTE merge-strategy change, since the gateway yarpc file embeds the transitive mergestrategy descriptor.Test Plan
bazel test //stovepipe/...— all targets passmake fmt,make lint-license,make gazelle— clean / idempotentmake protoreproduces the committed descriptorsTest Plan
Issues
Stack