05 — Coleta por remessa: o lote nunca mais sai pela metade

Status: Aprovado · Responsável: Gustavo Madruga · Atualizado em: 2026-09-09

Entregue em v0.0.12–v0.0.13 (2026-09-08 e 2026-09-09).

Escopo

O defeito que originou a etapa é concreto: a coleta fazia um SELECT por tabela e o PowerSync grava no SQLite local a qualquer momento — inclusive no meio da coleta. Os primeiros SELECTs rodavam antes de um lote de sync aterrissar, os últimos depois; o arquivo saía com o pedido sem o cliente, o ZIM devolvia 120 - Cliente não cadastrado, e 1XX é terminal: o pedido ficava órfão para sempre (pedido 260079421, 2026-09-08).

O que foi construído

Duas vias que convivem:

• Por remessa — o Integrador declara, a cada push, o conjunto que precisa chegar junto ao ERP (o manifesto, que desce pelo PowerSync). A linha coberta por uma remessa viva só sai quando a remessa está inteira no banco local: falta um item, nada dela viaja. O cliente lê as flags que o servidor calcula (bloqueado, resolvido, total_itens) e não deduz dependência nenhuma.
• Por presença — a linha que não pertence a remessa nenhuma sai como sempre saiu, depois de 3 ciclos de carência. O servidor só cria remessa onde há dependência, então cadastro avulso nunca terá uma; daqui, "linha cuja remessa ainda não chegou" e "linha que nunca terá remessa" são o mesmo estado observável.

Por cima disso, a coleta lê duas vezes e confere a passada inteira, manifesto incluído — banco que não sossega em três tentativas adia o lote. E o corte no teto de 999 registros respeita remessas inteiras, nunca pela metade.

Nada espera calado: remessa travada, remessa retida há muitos ciclos e item de tabela que o fluxo não conhece viram aviso no log e no GlitchTip, deduplicado por causa.

Decisões

Decisão	Assunto
0003	leitura dupla com conferência (superada pela 0004)
0004	a unidade de entrega é declarada na origem