User story
Como o worker de coleta, eu quero registrar o ciclo de um repositório que não tinha nada a analisar,
para que o digest dele não fique sem registro e ele não volte pendente em todo ciclo, para sempre.
Acceptance criteria
Por que rota separada, e não uma segunda forma de payload no /api/ingest
O que isso compra é que o corpo do /api/ingest continua tendo uma forma só, ganhando apenas o
campo refs_digest: o agente local não vê diferença nenhuma, e não há união de payloads para validar
nem para errar.
O que o poder desta rota realmente é
O que sobra é o que o token de ingestão já podia fazer de qualquer forma: avançar o watermark de um
repositório da própria organização e com isso fazer o worker saltar uma análise. É negação de dado,
não vazamento.
O dashboard continua honesto sem esforço
O repo_metric_summaries da migration 022 lê de metrics, então a run sem métrica não infla a
contagem de execuções nem move a data da última.
Se encaixa em qual estágio?
Stage 2 — Ingestion: reliability, token auth, idempotency.
Implementation notes
Sem esta rota, a análise que não encontra nada na janela termina sem emitir métrica e o repositório
volta pendente em todo ciclo, indefinidamente — custando um clone por ciclo para sempre.
Links
Bloqueado por
A coluna refs_digest e o índice único: #217. Sem eles a rota existe mas erra em runtime — nada em uso quebra, porque ninguém a chama ainda.
User story
Como o worker de coleta, eu quero registrar o ciclo de um repositório que não tinha nada a analisar,
para que o digest dele não fique sem registro e ele não volte pendente em todo ciclo, para sempre.
Acceptance criteria
POST /api/ingest/watermarks— mesmo caminho doGET, outro verbo, porque o recurso é o mesmorepository,window_dayserefs_digest/api/ingest/usagejá fazanalysis_runscomcommits_totalzero e responde 200 — ou 200 comduplicate: true, pelo mesmo índice únicometrics— e por construção, não por validação: não tem caminho para issocenso não conhece", mas a checagem é contra a tabela
repositories— que o censo da Fase 4 passa apreencher para a organização inteira. Nesta fase ela contém só o que já ingeriu alguma vez, e isso
basta: esta issue não depende do censo existir.
commits_total,github_usernemactive_usersdo clientePor que rota separada, e não uma segunda forma de payload no
/api/ingestO que isso compra é que o corpo do
/api/ingestcontinua tendo uma forma só, ganhando apenas ocampo
refs_digest: o agente local não vê diferença nenhuma, e não há união de payloads para validarnem para errar.
O que o poder desta rota realmente é
O que sobra é o que o token de ingestão já podia fazer de qualquer forma: avançar o watermark de um
repositório da própria organização e com isso fazer o worker saltar uma análise. É negação de dado,
não vazamento.
O dashboard continua honesto sem esforço
O
repo_metric_summariesda migration 022 lê demetrics, então a run sem métrica não infla acontagem de execuções nem move a data da última.
Se encaixa em qual estágio?
Stage 2 — Ingestion: reliability, token auth, idempotency.
Implementation notes
Sem esta rota, a análise que não encontra nada na janela termina sem emitir métrica e o repositório
volta pendente em todo ciclo, indefinidamente — custando um clone por ciclo para sempre.
Links
Bloqueado por
A coluna
refs_digeste o índice único: #217. Sem eles a rota existe mas erra em runtime — nada em uso quebra, porque ninguém a chama ainda.