Adota Solid Queue como fila persistente em produção

[Hirley]

Closes #77. Fecha o achado de alta prioridade da avaliação técnica: a fila vivia na memória do processo web.

Não havia queue_adapter configurado em lugar nenhum, então valia o default do Rails — :async. Todo restart, deploy ou OOM descartava em silêncio o que ainda não tinha rodado, incluindo as retentativas de webhook que o #86 acabou de introduzir e que, por definição, ficam pendentes por algum tempo.

A prova, com o compose de verdade

Specs não cobrem isto — o adapter em teste é o :test. Então verifiquei subindo a stack:

1. worker parado          → job enfileirado pelo web → 1 pendente no banco
2. docker compose restart web  (simula um deploy)    → 1 pendente ainda lá
3. worker de volta                                    → 0 pendentes, finished_at preenchido

O passo 2 é o ponto: com :async, aquele job teria desaparecido.

Decisões

Mesmo banco da aplicação, e não o banco separado que o instalador do Solid Queue assume. Multi-banco obrigaria a reescrever o config/database.yml inteiro — incluindo o caminho de DATABASE_URL, que é o que o Railway injeta — para resolver um problema de escala que este projeto não tem. O db/queue_schema.rb da gem virou uma migration comum, com o motivo registrado nela.

Produção usa :solid_queue; desenvolvimento continua no :async. Exigir um segundo processo para bin/rails server quebraria o fluxo de setup que o README documenta. A durabilidade importa onde há deploy.

O worker espera o web ficar saudável, não só o banco. É o entrypoint do web que aplica as migrations; subir antes faria o worker procurar tabelas que ainda não existem. E ele não roda migration nenhuma de propósito — dois processos preparando o mesmo banco ao mesmo tempo é corrida, não redundância. (Isso encosta na #82, que trata de tirar as migrations do boot do web; aqui só garanti que o worker não piora o quadro.)

Build e ambiente saem de âncoras YAML compartilhadas. Duas listas separadas divergiriam na primeira variável nova que alguém esquecesse de copiar, e o sintoma seria um job se comportando diferente da tela — caro de diagnosticar.

Três detalhes que valem o comentário que receberam

• O HEALTHCHECK da imagem faz curl na porta 3000. Faz sentido para o web, não para o worker, que não serve HTTP — desligado no serviço, senão ficaria eternamente unhealthy por não responder algo que nem deveria responder.
• config/recurring.yml existe vazio só para o worker parar de avisar que não encontrou o arquivo. Ruído permanente num log é ruído que se aprende a ignorar.
• As duas migrations do Solid Queue são schema da gem copiado, não código nosso: entraram na exclusão do RuboCop pelo mesmo critério já aplicado ao db/schema.rb. Sem isso são 287 ofensas, e reformatá-las faria o próximo solid_queue:update virar conflito.

Efeito colateral que vale declarar

O Gemfile.lock ganhou a plataforma x86_64-linux, resultado de resolver as gems dentro do container. É uma melhoria — o lockfile passa a descrever a plataforma onde a aplicação de fato roda, e era inclusive uma das recomendações da avaliação. O bundle lock --add-platform do Dockerfile continua ali como rede de segurança, agora como no-op.

Verificação

	resultado
RuboCop	105 arquivos, 0 offenses
Zeitwerk check	All is good!
RSpec	375 exemplos, 0 falhas
docker compose up --build	três serviços saudáveis, na ordem certa
Job de ponta a ponta	enfileirado pelo web, executado pelo worker, 0 falhas
Durabilidade	sobrevive a restart do web com o worker parado

O que continua em aberto

O adapter de desenvolvimento segue :async, então lá os jobs ainda se perdem — documentado no README, e é o trade-off deliberado acima. E a #82 (migrations acopladas ao boot do web) fica mais visível agora que há dois processos: hoje o worker depende do web ter subido para que o banco esteja pronto.

🤖 Generated with Claude Code