S11-FOLLOWUP — janela de lock: sync de render acoplado à duração do sync no save de credenciais #124

New issue

Closed

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

fsolla commented

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

Owner

depends

serializes

priority

model

S11-FOLLOWUP

115

composer-2.5

Do /simplify da S11 (issue #115). O afterChange da global social-feed-settings faz o sync awaited dentro da transação do save (correto para que o reload mostre o status novo e os persists não deadlockem — a row lock é necessária). Porém:

O fetch de rede do loadInstagramFeed (até INSTAGRAM_SYNC_TIMEOUT_MS = 10s) roda dentro da transação, segurando a row lock da social_feed_settings por todo o fetch.
Como o mesmo hook também faz revalidateTag('social-feed') (busta a tag), o re-render da home re-executa getInstagramFeed → seu persistInstagramSyncStatus/persistInstagramSnapshot (pool) fica bloqueado na row lock até o commit — acoplando a latência da home pública (ISR) à duração do sync de credenciais (até ~10s no pior caso) num save.

Fail-closed preservado (não quebra), mas é um acoplamento evitável.

Candidatos a mitigação (avaliar):

Reduzir o timeout do sync no hook (ex.: 5s) — trade-off com a rede da Graph API.
Fazer o fetch de rede ANTES de abrir/avisar o persist transacional, mantendo só as escritas no lock (o fetch não precisa da row lock).
Persistir o status pós-commit (fire-and-forget) ao custo de o reload pós-save não mostrar o estado imediato (perde parte do aceite da intenção).

Sem urgência (save de credenciais é raro); registrar e decidir num item futuro.

--- id: S11-FOLLOWUP depends: [115] serializes: [] priority: P2 model: composer-2.5 --- Do /simplify da S11 (issue #115). O `afterChange` da global `social-feed-settings` faz o sync **awaited dentro da transação do save** (correto para que o reload mostre o status novo e os persists não deadlockem — a row lock é necessária). Porém: - O fetch de rede do `loadInstagramFeed` (até `INSTAGRAM_SYNC_TIMEOUT_MS` = 10s) roda **dentro da transação**, segurando a row lock da `social_feed_settings` por todo o fetch. - Como o mesmo hook também faz `revalidateTag('social-feed')` (busta a tag), o re-render da home re-executa `getInstagramFeed` → seu `persistInstagramSyncStatus`/`persistInstagramSnapshot` (pool) fica **bloqueado na row lock até o commit** — acoplando a latência da home pública (ISR) à duração do sync de credenciais (até ~10s no pior caso) num save. Fail-closed preservado (não quebra), mas é um acoplamento evitável. **Candidatos a mitigação (avaliar):** 1. Reduzir o timeout do sync no hook (ex.: 5s) — trade-off com a rede da Graph API. 2. Fazer o fetch de rede ANTES de abrir/avisar o persist transacional, mantendo só as escritas no lock (o fetch não precisa da row lock). 3. Persistir o status pós-commit (fire-and-forget) ao custo de o reload pós-save não mostrar o estado imediato (perde parte do aceite da intenção). Sem urgência (save de credenciais é raro); registrar e decidir num item futuro.