T-063 - Implementar o loop consumidor de `executar-codigo`

[pedro-fs-garcia]

T-063 - Implementar o loop consumidor de executar-codigo

• Componente: worker

• Estimativa: 3

• Depende de: T-010, T-021

• Data máxima: 2026-09-21 (seg)

Descrição

Implementar o consumer de executar-codigo do worker, com prefetch 1, que lê o código pela referência do evento e prepara o payload de execução retendo o orçamento fora do que será entregue ao container.

A porta de entrada do worker: consome o comando, lê do Postgres o código a executar pela referência recebida e prepara a execução.

Só o código entra de fora. O dataset e os baselines já estão dentro da imagem - não há busca nem materialização por job.

Escopo

Dentro do escopo

• Consumer de executar-codigo com prefetch 1 e DTO escrito à mão.
• Leitura do código no Postgres pela referência do evento, com o usuário de banco do worker.
• Validação de que o job_id e a referência existem, com erro claro quando não existirem.
• Preparação do payload de execução, incluindo o critério de orçamento recebido.

Fora do escopo

• Subida do container e flags de isolamento (T-064).
• Coleta e classificação do resultado (T-065).
• Cálculo do veredito (T-066) e publicação (T-067).
• Política de retry, que depende da classificação de falhas de T-065.

Requisitos

• prefetch 1: uma execução por vez, para não travar múltiplas execuções longas numa instância única.
• O worker tem apenas SELECT na tabela de código; qualquer outra operação falha por permissão.
• Um comando cujo código não existe é recusado com erro específico, não com falha genérica de execução.
• O critério de orçamento é retido no processo do worker, fora do que será entregue ao container.

Contexto técnico

• Entradas: comando executar-codigo (T-057); usuário de banco (T-021); worker executável (T-010).
• Saídas: código carregado e payload de execução preparado.
• Componentes afetados: worker/; RabbitMQ; banco.
• Restrições: comando tem semântica de retry distinta de evento; nesta fase há uma única instância consumindo sequencialmente.
• Referências: ARCHITECTURE.md §3.4 (loop consumidor, preparação do container) e §6.3.

Critérios de aceitação

• O consumer recebe o comando do RabbitMQ do compose com prefetch 1.
• O código é lido do Postgres pela referência do evento.
• Um comando com referência inexistente é recusado com erro específico.
• Uma tentativa de UPDATE na tabela de código falha por permissão.
• O DTO passa no teste de contrato contra contracts/examples/.
• Dois comandos enfileirados são processados um de cada vez.

Definição de concluído (DoD)

• Todos os critérios de aceitação foram atendidos.
• Testes automatizados foram adicionados ou atualizados quando aplicável.
• Os testes existentes passam.
• O código segue as convenções e padrões de qualidade do projeto.
• Documentação, migrações, contratos ou configurações exigidos foram atualizados.
• Nenhuma regressão conhecida ou problema não resolvido foi introduzido pela tarefa.
• As alterações foram confirmadas e estão prontas para revisão/mesclagem.
• A implementação foi verificada no ambiente apropriado.

Observações / Decisões

O orçamento nunca entra no container. Ele é recebido aqui e retido no processo do worker, para uso em T-066. Se descesse junto com o código, o veredito estaria no mesmo processo do código não confiável, que poderia adulterá-lo.

Efeito cascata: destrava T-064 e abre a trilha do worker, a mais longa do M3.