fix(storefront): Stop sending an expired login to the checkout app

[vitorrgg]

Problema

Cliente já cadastrado volta à loja depois que o token do passport expirou. O cookie ecomPassportClient continua com o token vencido (6 dias), o app.js legado confia em qualquer auth.id (checkLogin() não valida expiração), faz GET /customers/:id, recebe 401, faz logout() e o checkout fica no formulário "Complete seu cadastro" como cliente novo. Relato recorrente da Barradoce desde 05/2026, ainda reproduzido em 15/09 após o #785 e o beta.228.

Reproduzido em produção com Playwright: token vencido no ecomSession + cookie antigo + sem usuário Firebase → nenhum POST em /_api/passport/token, 2x 401 e AccountForm. Quando a renovação do #785 não acontece (sem usuário Firebase o app carrega na hora; falha ou cold start > 10s em /_api/passport/token), o resultado é sempre esse.

Mudança

No watch(isAuthenticated) do vbeta-app, quando a sessão não está autenticada e o app.js ainda não carregou, apaga o cookie ecomPassportClient se ele tiver auth.level === 3 (só o Cloud Commerce grava esse nível). Identificações legadas por e-mail + documento (nível 0 a 2) não são tocadas. O app.js sobe sem identificação, mostra a tela de e-mail, e recebe o evento login via setSession assim que o token é renovado.

Complementa ecomplus/storefront (fix/checkout-recover-from-401), que faz o checkout voltar à identificação quando o fetch do cliente falha.

Teste

Preview na Barradoce com este vbeta-app (override local) + build do storefront-app com o fix. Mesmo cenário do Playwright termina na tela de e-mail, sem 401.

🤖 Generated with Claude Code

[vitorrgg]

Resultado do teste no preview

Preview: https://ecom2barradoce--pr134-fix-checkout-recover-tv82ga7c.web.app (storefront-app com ecomplus/storefront#1314 + vbeta-app com #842)

Cenário	Produção (beta.228 + 2.63.2)	Preview
Sem sessão (controle)	tela de e-mail	tela de e-mail
Token vencido + cookie ecomPassportClient nível 3 + sem usuário Firebase	2x 401 em /customers/:id → "Complete seu cadastro"	nenhum 401, cookie apagado antes do app.js → tela de e-mail
Cookie legado nível 2 com token inválido (isola o fix do storefront-app)	2x 401 → "Complete seu cadastro"	2x 401 → resetAccount → tela de e-mail
Token inválido com expires no futuro	2x 401 → redirect para a home	2x 401 → redirect para a home (fora do escopo, listener de logout do vbeta-app)

Script: Playwright headless, sem criar pedido. Fica em cloud-commerce/temp/checkout-login-bug-test.mjs na máquina do Vitor (ORIGIN=<url> TAG=<tag> node checkout-login-bug-test.mjs).

[vitorrgg]

Revisão adversarial

Escopo

A PR deveria: apagar o cookie ecomPassportClient de nível 3 quando a sessão Cloud Commerce não está autenticada e o app.js ainda não carregou, sem tocar identificações legadas (nível 0 a 2) nem o caminho de sessão válida. Não deveria mudar a espera do #785 nem o listener de logout. O diff bate com isso: um helper novo e um else extra no watch(isAuthenticated).

Premissas verificadas

• Nível 3 só nasce no vbeta-app. A identity API do Cloud Commerce (packages/passport/src/firebase/serve-passport-api.ts) devolve nível 0, 1 ou 2, e o @ecomplus/client roteia identify, token e oauth-providers para ela via ECOMCLIENT_API_PASSPORT_IDENTITY. O fetchLogin do LoginBlock legado nunca chega a 3 numa loja v3.
• Deleção casa com o cookie gravado. setCookie do sf-utils e o set-cookie do passport-client usam os mesmos atributos (path=/; samesite=strict, valor JSON cru), então setCookie(key, '', -1) remove o cookie escrito por qualquer um dos dois.
• Nova aba não regride. ecomSession fica em localStorage, não em sessionStorage. Sessão válida em outra aba continua isAuthenticated, cai no if, e o cookie é reescrito, não apagado.
• Ordem de execução. O watch com immediate: true roda de forma síncrona antes de qualquer loadAppScript(). Quando o Firebase renova o token, o session.auth = enfileira o watcher em microtask, que reescreve o cookie antes do isAuthReady liberar o app.js. Não há janela em que o app.js leia cookie ausente com token já renovado.
• else if (ecomPassport) refatorado é equivalente ao ecomPassport?.checkLogin() anterior para o caso com app.js carregado.
• ESLint na branch: limpo (só os no-console pré-existentes).

Achados

Nenhum Critical ou Required.

Optional

1. Sem teste automatizado (vbeta-app.ts:271-284). clearStalePassportCookie está inline e não é exportável. Extrair para um helper (por exemplo em @@sf/sf-lib ou src/lib/helpers/) e cobrir em packages/storefront/tests com jsdom: cookie nível 3 é removido; nível 2 e nível 0 ficam; JSON inválido é removido; ausência de cookie não escreve nada. É o teste que trava a regressão "apagou cookie legado".

2. Rollout acoplado ao storefront#1314. O pin continua em beta.228. A PR resolve sozinha o cenário "token vencido + cookie nível 3", mas o cenário "cookie legado nível 2 com token inválido" depende do resetAccount do #1314, que ainda não foi publicado. Vale registrar no PR que o bump para beta.229 vem em commit seguinte, senão a release fecha metade do bug.

3. Sem sinal de observabilidade. O fix roda silencioso. Um console.info ou evento gtag ao apagar o cookie permitiria confirmar em produção que a taxa de 2,4% de checkouts logados sem _id cai, em vez de esperar novo relato da Barradoce.

Nit

4. decodeURIComponent antes do JSON.parse (vbeta-app.ts:277): o cookie é gravado como JSON cru pelos dois lados, então o decode é só defensivo. Se um dia o valor tiver % literal, o catch apaga um cookie legado válido. Aceitável hoje, mas o comentário "malformed, drop it anyway" esconde esse caso.

5. logout() em customer-session.ts continua sem limpar o cookie quando o app.js não está carregado; esta PR cobre isso só no próximo load de /app/. Fora do escopo, fica como nota.

Eixos sem achado

• Regressão: sessão válida, sessão anônima sem cookie e app.js já carregado seguem o caminho antigo.
• Auth: nada novo vai para log, URL ou request. O helper só lê e apaga cookie local.
• Fila, integração, aggregation: não se aplicam.

Veredito

APROVAR COM RESSALVAS. A mudança é correta e mínima. As ressalvas são teste de regressão (item 1) e deixar explícito o acoplamento de rollout com o beta.229 (item 2).

Não verificado: tsc --noEmit na branch; resultado do Playwright no preview (tomei o comentário da PR como dado); se alguma loja injeta cookie nível 3 por código próprio via _appScriptSrc ou custom functions.

[leomp12]

Mudança bem delimitada. O critério de level === 3 confere: a API do passport do Cloud Commerce só grava níveis 0 a 2 (packages/passport/src/firebase/serve-passport-api.ts), então a identificação legada fica intacta. O fluxo também se encaixa no gate do #785: se a renovação acontece, o watch grava o cookie novo antes de o app.js subir; se não acontece, o app sobe sem identificação em vez de subir com token vencido. Os casos de cookie malformado ou sem auth estão cobertos.

Empurrei dois commits no branch:

• 3ab14f8a0 atualiza o @ecomplus/storefront-app para 2.0.0-beta.229, que tem o ecomplus/storefront#1314. Sem esse bump o complemento do lado do app não chegava às lojas. A 229 ficou alguns dias fora do npm por causa da falha no publish (ecomplus/storefront#1317); conferi que agora está no npm e no jsDelivr/unpkg.
• 04e012fca reduz o comentário do clearStalePassportCookie ao motivo do código; a história do bug já está no commit e na descrição do PR.

🟢 Minor: o #812 insere código logo depois do watch(customer), bem perto deste trecho. Quem mergear depois pode precisar de um rebase simples.