Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

submitqueue: port internal queue contracts to proto (submitqueue/core/messagequeue)

Aberta
  • Algo errado?
#356 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 2 dias

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
32/100
Tipo de issue
Refatoração
Clareza
Razoavelmente clara
Status de atividade
Pouca atividade
Stack de tecnologia
go
Domínio
distributed-systems

Direção de pesquisa

Comece por doc/rfc/messagequeue-contract.md e compare api/runway/messagequeue/ com stovepipe/core/messagequeue/. Mapeie os doze tópicos entre gateway Land/Cancel, os stage controllers do orchestrator, core/request.PublishLog e os controladores de DLQ e as ferramentas de republish. Está concluído quando submitqueue/core/messagequeue/ tiver os contratos proto, o protopb gerado, glue, bindings e testes de contrato, todos os usuários de payload tiverem sido migrados e os entity serializers listados tiverem sido removidos.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Problem

The repo's queue-contract convention (doc/rfc/messagequeue-contract.md) is proto3 payloads serialized as protojson, with a contract package owning both the messages and their topic_keys bindings — api/runway/messagequeue/ is the reference example and stovepipe/core/messagequeue/ follows it. The submitqueue domain has not been ported: there is no submitqueue/core/messagequeue/ package, and 11 of its 12 topics still carry hand-rolled JSON via ToBytes/FromBytes methods on entity types.

Current state per topic:

Topic key Payload Serialization
start RequestID entity JSON
cancel CancelRequest entity JSON
validate RequestID entity JSON
batch RequestID entity JSON
score BatchID entity JSON
speculate BatchID entity JSON
prioritize QueueID entity JSON
build BatchID entity JSON
buildsignal BuildID entity JSON
conclude BatchID entity JSON
log RequestLog entity JSON
merge MergeRequest ✅ protojson (api/runway/messagequeue — correctly borrowed; runway owns that queue's contract)

Consequences of the split: no additive-evolution guarantees (protojson's unknown-field discard, UPPER_SNAKE enums, int64-as-string are only enforced on merge), no topic_keys binding or contract test for internal topics, and queue-payload serialization concerns living on domain entities (which are supposed to be pure data).

Work

  1. Create submitqueue/core/messagequeue/ mirroring the reference layout: proto/ sources, committed protopb/, and the generic protojson glue (Marshal / Unmarshal[T] / TopicKeys) — same as stovepipe/core/messagequeue/.
  2. Define proto messages for each payload shape (request-ID carrier, batch-ID carrier, build-ID carrier, queue-ID carrier, cancel request, request log) and bind each topic key to its message via the topic_keys option from api/base/messagequeue.
  3. Add the contract test: protojson round-trip per message + every topic key bound to exactly one message.
  4. Migrate producers and consumers topic by topic (gateway Land/Cancel publishes, all orchestrator stage controllers, core/request.PublishLog, and the DLQ controllers/republish tooling — anything touching msg.Payload).
  5. Once no queue payload uses them, remove ToBytes/FromBytes from the submitqueue entity types (RequestID, BatchID, BuildID, QueueID, CancelRequest, RequestLog, and the full-entity variants) so entities go back to being pure data.
  6. Bazel visibility stays domain-scoped per the internal-contract rule.

Caveats

  • Wire-format flip: protojson output (snake_case fields, int64-as-string) differs from the current encoding/json entity output, so in-flight messages from before a cutover won't parse after it. Port topic-by-topic with drained queues (fine at the current pre-prod stage), or give consumers a transitional dual-format read if needed.
  • The log topic crosses gateway ↔ orchestrator but both are submitqueue-domain services, so the internal contract location (submitqueue/core/messagequeue/) is correct — it must not go under api/.
  • The message-ID convention is a separate concern tracked in #352 (intent-scoped message IDs); porting payloads to proto neither depends on nor resolves it, but call sites will be touched by both — coordinate to avoid churn.

Related

  • #352 — intent-scoped message IDs (same call sites)
  • #357 — stovepipe counterpart (retire leftover JSON serializers, contracts for upcoming stages)
Linguagem predominante
Go
Estrelas
227
Forks
11
Merge médio
3d 49min
PRs com merge (30d)
63

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de uber/submitqueue

Todas as issues de uber/submitqueue

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.