S11-POLISH — rota de sync: 200 ok:false em não-configurado e tipo de persist duplicado #125

New issue

Closed

opened 2026-08-20 03:11:57 +00:00 by fsolla · 1 comment

fsolla commented

2026-08-20 03:11:57 +00:00

Owner

depends

serializes

priority

model

S11-POLISH

115

composer-2.5

Do /simplify da S11 (issue #115), achados P3 absorvidos como débito (nenhum bloqueio de merge):

InstagramPersistDatabase (instagramFeed.ts) duplica PostgresTransactionDatabase (postgresTransactionLocks.ts) — ambas são { execute } estruturais. resolvePersistDatabase poderia reusar o tipo do helper existente em vez de redeclarar; a única razão foi evitar o acoplamento do módulo de persist ao módulo de locks. Reavaliar se vale a importação do tipo.
Rota POST /api/social-feed/sync retorna 200 { ok: false, status: {} } quando o IG fica não-configurado (o syncInstagramFeed retorna {}), divergindo do impl doc que previa 400 { ok: false, error }. Como o painel não renderiza o botão nesse estado (defesa), não é falha de segurança — apenas alinhar impl doc ↔ código (ou devolver 400).
jsonb last-writer-wins: uma render que carregou settings antigas pode persistir snapshot/status stale DEPOIS do hook commitado o sucesso com credenciais novas (disparos assíncronos do revalidate + pool vs transação). Regressão temporária auto-curável no próximo render/save (cache 300s). Se incomodar num item futuro, versionar uma seq/timestamp no status.
admin.e2e.spec.ts crava · 5 posts no número de POSTS do stub — guard explícito determinístico; quebra silenciosamente se o stub ganhar um post. Manter como está (intenção), só registrar.

--- id: S11-POLISH depends: [115] serializes: [] priority: P3 model: composer-2.5 --- Do /simplify da S11 (issue #115), achados P3 absorvidos como débito (nenhum bloqueio de merge): 1. **`InstagramPersistDatabase` (instagramFeed.ts) duplica `PostgresTransactionDatabase` (postgresTransactionLocks.ts)** — ambas são `{ execute }` estruturais. `resolvePersistDatabase` poderia reusar o tipo do helper existente em vez de redeclarar; a única razão foi evitar o acoplamento do módulo de persist ao módulo de locks. Reavaliar se vale a importação do tipo. 2. **Rota `POST /api/social-feed/sync` retorna `200 { ok: false, status: {} }` quando o IG fica não-configurado** (o `syncInstagramFeed` retorna `{}`), divergindo do impl doc que previa `400 { ok: false, error }`. Como o painel não renderiza o botão nesse estado (defesa), não é falha de segurança — apenas alinhar impl doc ↔ código (ou devolver 400). 3. **`jsonb` last-writer-wins: uma render que carregou settings antigas pode persistir snapshot/status stale DEPOIS do hook commitado o sucesso com credenciais novas** (disparos assíncronos do revalidate + pool vs transação). Regressão temporária auto-curável no próximo render/save (cache 300s). Se incomodar num item futuro, versionar uma seq/timestamp no status. 4. **`admin.e2e.spec.ts` crava `· 5 posts` no número de `POSTS` do stub** — guard explícito determinístico; quebra silenciosamente se o stub ganhar um post. Manter como está (intenção), só registrar.