Status
The stovepipe domain is mostly on the proto queue-contract convention (doc/rfc/messagequeue-contract.md): its one live topic, process, uses ProcessRequest from stovepipe/core/messagequeue/ with protojson glue, topic_keys binding, and the reference layout. This issue covers the remaining gaps so the domain ends up — and stays — proto-only.
Work
- Retire the leftover JSON payload serializers.
stovepipe/entity/request.go still exposes ToBytes/FromBytes on Request and RequestID, documented as "for queue message payload" — but no queue uses them anymore (ingest publishes ProcessRequest proto; process consumes it). Remove them (or, if some non-queue use exists, re-document them so they stop advertising themselves as queue serialization). As long as they exist, the next stage's author has an attractive wrong tool one import away.
- Proto contracts for upcoming stages from day one.
process.go carries the TODO "re-publish to build once the build stage lands (RFC process algorithm, step 3)" — the build stage (and any later stovepipe queues) must define their payloads in stovepipe/core/messagequeue/ with topic_keys bindings before the controller lands, extending the existing contract test (round-trip + one message per topic key) rather than reaching for entity JSON.
- Audit in-flight stovepipe PRs (e.g. the admit-latest-head-through-process work) for any queue payload that bypasses the proto contract package, and route them through it before merge.
Caveats
Related
Status
The stovepipe domain is mostly on the proto queue-contract convention (doc/rfc/messagequeue-contract.md): its one live topic,
process, usesProcessRequestfromstovepipe/core/messagequeue/with protojson glue,topic_keysbinding, and the reference layout. This issue covers the remaining gaps so the domain ends up — and stays — proto-only.Work
stovepipe/entity/request.gostill exposesToBytes/FromBytesonRequestandRequestID, documented as "for queue message payload" — but no queue uses them anymore (ingest publishesProcessRequestproto; process consumes it). Remove them (or, if some non-queue use exists, re-document them so they stop advertising themselves as queue serialization). As long as they exist, the next stage's author has an attractive wrong tool one import away.process.gocarries the TODO "re-publish to build once the build stage lands (RFC process algorithm, step 3)" — thebuildstage (and any later stovepipe queues) must define their payloads instovepipe/core/messagequeue/withtopic_keysbindings before the controller lands, extending the existing contract test (round-trip + one message per topic key) rather than reaching for entity JSON.Caveats
Related