mirror of
https://github.com/fsolla/teqo.git
synced 2026-11-15 02:23:07 +00:00
Registra o fechamento da #811: o login REST não-serializado do usuário
compartilhado em frontend.e2e.spec.ts foi eliminado pelo commit d0161f6d
(Closes #767), que unificou todos os logins no helper adminHeaders travado
por advisory lock. Nenhuma mudança de código; apenas changelog + impl plan.
3.9 KiB
3.9 KiB
Impl: E2E-FRONTEND-LOGIN-SHADOW — shadow local de adminHeaders ignora o advisory lock
Status: aprovado-parcial (defeito já resolvido por #767)
Atualizado em: 2026-08-24
Issue: #811
Intenção: body da Issue #811 (sem doc docs/plans/ linkado)
Appetite restante: herdado (~0,25 dia) — na prática 0 (ver abaixo)
Leitura da intenção
- Outcome: Nenhuma família de e2e mantém login REST não-serializado do usuário
compartilhado (
dev@payloadcms.com) — evitar a race read-modify-write de sessões do Payload (perda de sessão → 403 no e2e full com 4 workers). - O que NÃO negociar: não mexer no retry 403→relogin do
campaignHomePixel(#760); não trocar login de UI por API login nos specs de formulário; não serializar projetos/workers inteiros. - O que reavaliar: o "shadow local de
adminHeaders" citado emfrontend.e2e.spec.ts:613não existe mais no estado atual.
Achado determinante (exploração)
- #811 foi criada em 2026-08-23T22:00Z. O commit
d0161f6dtest(e2e): unificar logins do usuário de teste no helper adminHeaders com advisory lock (Closes #767) foi mergeado em 2026-08-24T18:42Z — depois da abertura da #811. - Esse commit removeu o login inline de
frontend.e2e.spec.tse o substituiu poradminHeadersimportado de../helpers/adminApi(que carregawithAdvisoryLock(ADMIN_LOGIN_LOCK_KEY, …)). O shadow local desapareceu. - Verificação por grep no estado atual (branch = HEAD
fcefcac4, sem diff vsmain):users/loginaparece só emtests/helpers/adminApi.ts(o helper serializado). Zero ocorrências inline emtests/e2e/*.- Nenhum construtor custom de cookie
payload-tokenfora do helper (excetocampaignHomePixel, que usaadminHeaders+ retry 403 — intocável por contrato). - Todas as 14 chamadas em
frontend.e2e.spec.tsusamadminHeaders(request, baseURL)(linhas 609, 819, 977, 1010, 1091, 1144, 1208, 1298, 1358, 1429, 1497, …).
Abordagem recomendada
flowchart LR
A[Estado atual] --> B{grep confirma 0 login inline?}
B -- sim --> C[Defeito já resolvido por #767]
C --> D[Fechar #811 como satisfeita por #767]
Opções consideradas: A) reaplicar withAdvisoryLock a um shadow inexistente
| B) rotear o shadow (inexistente) pelo helper | C) apenas verificar e fechar.
Recomendação: C — não há código a mudar; o requisito de aceite da #811 já
está satisfeito no HEAD.
Rejeitadas: A e B — o alvo (shadow local) não existe mais; mexer no arquivo
para "corrigir" o inexistente seria churn sem benefício (viola "editar o dono,
não gêmeo" e o princípio de não adicionar código morto).
Componentes / mudanças
- Sem migration (muda só teste, e nem teste muda).
- Sem mudança de código.
Decisão de fechamento
- Fechar #811 com
Closes #811apontando que #767 unificou os logins e resolveu a race; incluir o grep de verificação no corpo do PR.
Fases verificáveis
- Verificação (feita): grep de
users/loginepayload-tokenemtests/e2e,tests/integration,tests/helpers— limpo. - Fechamento: PR com nota de verificação →
Closes #811.
Rabbit holes / Não escopo (engenharia)
- Não tocar o retry 403→relogin do
campaignHomePixel(#760). - Não trocar login de UI por API login nos specs de formulário.
- Não serializar projetos inteiros nem workers.
Riscos e mitigação
- Regressão futura (shadow volta): sem guarda automática, um novo login
inline pode reaparecer. Mitigação opcional (fora do appetite mínimo): um check
de CI que falhe se
users/loginaparecer fora dehelpers/adminApi.ts. Deixar para o humano decidir no GATE.
Aceite de engenharia
- Aceite de produto da intenção coberto (nenhum login não-serializado resta)
- Invariantes AGENTS/engineering-standards preservados (não mexeu em nada)
- Testes de domínio: N/A (nenhuma write path mudou)