OPS52-media — OPS52-media — Recuperar os arquivos de media de produção (40 rows com URLs locais e nenhum arquivo em disco) #10
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Plano:
docs/plans/ops52-media-recuperar-arquivos.mdAchado da OPS51 (2026-08-17, migração Neon→homeserver): as 40 rows da collection
mediatêm URLs RELATIVAS (/api/media/file/…) e os arquivos não existem em lugar nenhum (workstation, homeserver, imagem —.dockerignoreexcluimedia/; pastamedia/não existe no repo). Consequência: as capas dos posts dão 500 no homeserver e 404 no próprio Vercel/produção atual (pt.jorgesolla.com.br) — estado pré-existente à migração (paridade mantida, sem regressão). O OPS51 registrou o achado; este item recupera os arquivos (fontes candidatas: Vercel Blob store — o seed de posts usa chaves determinísticas<slug>.<ext>; WordPress de origem; dumps antigos do Neon) e deixa as URLs resolvendo no storage definido pelo OPS52. Depende do OPS52 (storage real) para a forma final, mas a investigação de onde estão os arquivos pode começar antes.Gate do plano (2026-08-18): absorvido o relato "imagens dos artigos não carregam na seção de conteúdos da home de campanha (S1)". Causa raiz confirmada única: arquivos inexistentes (contrato de URL relativa via proxy comprovado no Payload 3.82 — uploads novos seguem servindo). Prioridade elevada P2→P1 no gate.
Promovido a
ready: plano de intenção emmain(ciclo OPS17 —pnpm agent:ready).Claimed by agent run at 2026-08-18T10:31:02.273Z. Lock otimista: outro claim deve falhar e re-rodar
pnpm agent:claim.Fechado pelo PR #38 (merge
45e29a77, CI verde incl. e2e). Entrega:pnpm media:recover(reconcile/--dry-run/--verify) + lib extraídascripts/lib/wpArticles.mjs(fetch WP + resolução de capa compartilhada com o seed, unit-testada). Fail-closed: S3_* completas,ALLOW_REMOTE_DB=true, echo do alvo, timeouts curtos, covers só do origin WP eimage/*. Runbook de execução em prod (pós-merge, homeserver):docs/plans/ops52-media-recuperar-arquivos-impl.md— inclui pre-flight container→Garage (a rota pública de media de prod pendurava >25s na sondagem; se persistir com objetos no bucket, é infra — abrir sucessor OPS). Dívida registrada: #37 (guard de intenção para escrita em bucket). ⚠️ Aceite 200/row depende da execução do runbook (ferramenta entregue; objetos ainda não restaurados — execução fica com o humano, fora da skill).Execução em prod concluída (2026-08-18) — aceite verificado:
teqo-mediaa partir do WordPress de origem (chaves determinísticas<slug>.<ext>, rows do DB intocadas); reexecutável compnpm media:recover(idempotente).--verify: 38/40 respondendo 200 emhttps://jorgesolla1313.com.br/api/media/file/...(era 000/timeout antes). Exceções honestas (404, sem fonte no WP, rows manuais não referenciadas):fim-escala-6x1.jpgejorgesolla.jpg._next/image); 0 requests falhados.headObjectpendurava). Fix: 2 regras ufw (allow from 10.0.11.0/24 to any port 3900, INPUT + route/FWD) +extra_hosts: host.docker.internal:host-gatewaynos serviçosteqo-1313/teqo-1313-migrate+S3_ENDPOINT=http://host.docker.internal:3900no~/stack/teqo-1313.env(backup do compose em.pre-ops52-media-hostgateway; sobrevive aos deploys OPS53). Detalhes no runbook (docs/plans/ops52-media-recuperar-arquivos-impl.md).Fechado em: PR #38 (ferramenta) + #41 (docs).