Skip to content

stovepipe: keep queue contracts proto-only — retire entity JSON serializers, contracts for upcoming stages #357

Description

@behinddwalls

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

  1. 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.
  2. 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.
  3. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions