fix(webhook): resolveBestJid deixa de priorizar dígitos-LID sobre telefone real - #130
Conversation
…efone real Bug encontrado durante a auditoria do E35 (normalizePhone): resolveBestJid usava a mesma regex de "10-15 digitos" para aceitar tanto telefones E.164 quanto LIDs sem sufixo @lid (que tambem caem nessa faixa, 14-15 digitos). Como a busca e por .find() em ordem de posicao do array de candidatos, se remoteJid trouxer o LID em digitos nus e remoteJidAlt trouxer o telefone real, o LID vencia so por estar primeiro — nao por ser mais confiavel. Aplica a mesma heuristica de tamanho que normalizePhone (E35, PR #120) para excluir digitos no formato LID (14-15 digitos) do tier de prioridade alta, com fallback para eles apenas depois de tentar @g.us e antes do fallback generico "nao-@lid". Validado: - typecheck (tsc --noEmit): OK - lint-ratchet: 0 novas ocorrencias - manifest de deploy: regenerado (supabase/deployment-manifest.json) - testes de contrato (vitest.contracts.config.ts): 167/167 passam - guards CI (scripts/ci/*.unit.mjs, scripts/edge-deploy/*.unit.mjs): 38/38 passam - supabase-usage-guard: 0 violacoes novas Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018N9zUcTpab3dWsuR3ZSSBj
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
adm01-debug has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
|
Warning Review limit reachedNext included review available in 49 minutes. View limit detailsLimit details: You’ve used the included review currently available. Your 98 included PR review attempts over the past 7 days set your current allowance at 1 review per hour. Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (2)
Comment |
There was a problem hiding this comment.
🟡 Changes recommended
A nova função isLidLengthDigits aceita + e pode tratar números E.164 válidos de 14–15 dígitos como “LID”, desfazendo a priorização pretendida em alguns cenários.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Ajusta a heurística de seleção de JID em webhooks para evitar que LIDs numéricos (14–15 dígitos sem @lid) sejam escolhidos antes de telefones reais, reduzindo fragmentação de contatos no fluxo Evolution.
Changes:
- Introduz um “tier” extra em
resolveBestJidpara empurrar dígitos com comprimento típico de LID para depois de@g.us. - Atualiza o
supabase/deployment-manifest.jsonpara refletir o novo hash/tamanho dos artefatos.
File summaries
| File | Description |
|---|---|
| supabase/functions/_shared/evolution-helpers.ts | Ajusta a prioridade de seleção de JID para não favorecer LID numérico sobre telefone real. |
| supabase/deployment-manifest.json | Regenera hashes/bytes do manifesto após a mudança em funções Supabase. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
There was a problem hiding this comment.
adm01-debug has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
…alogo/manifest com main (P2)
P1 (cubic): a excecao de 20260901200001 usava kind ledger-divergence/pinned-replay,
mas o ledger_sql_sha256 e SHA256("") — o ledger historico nao tem statements
(stmts_count=NULL, confirmado ao vivo). O branch pinned-replay do guard falha
incondicionalmente quando ledgerSql e vazio ("excecao pinned-replay exige
ledgerSql canonico nao vazio"), entao essa excecao deixava o step 7 vermelho
em vez de corrigi-lo. Troca para ledger-only/name-and-file-pinned, o kind
correto para ledger sem SQL/hash algum (so pina nome+arquivo) — mesmo padrao
ja usado nas outras excecoes comment-only deste arquivo.
P2 (cubic + Copilot): dedup_baseline_20260901 estava documentada em
schema-catalog.json/schema-manifest.json/types.ts sem migration correspondente
em supabase/migrations/. A tabela ja foi dropada (0 linhas, artefato de
auditoria pontual, confirmado ao vivo). supabase/schema-catalog.json,
supabase/schema-manifest.json e src/integrations/supabase/types.ts desta PR
estavam desatualizados desde 01/09 (antes do merge de #120/#125/#130); main ja
teve esses artefatos resincronizados pelo workflow automation/types-sync hoje
(02/09). Restaura os 3 arquivos para a versao atual de main em vez de tentar
reconciliar o diff antigo — nenhuma mudanca de schema nesta PR justifica um
snapshot proprio, e main ja e a fonte de verdade mais fresca.
Validado:
- node scripts/db-audit/check-migration-drift.mjs (offline): OK, 326 arquivos validos
- node --test scripts/db-audit/*.test.mjs: 118/118 passam
- node scripts/db-audit/supabase-usage-guard.mjs: 0 violacoes novas
- Confirmado ao vivo: supabase_migrations.schema_migrations.statements = NULL
para 20260901200001; dedup_baseline_20260901 nao existe em information_schema.tables
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018N9zUcTpab3dWsuR3ZSSBj
Problema
Follow-up da auditoria do E35 (
normalizePhone, PR #120):resolveBestJidusava a mesma regex de "10-15 dígitos" para aceitar tanto telefones E.164 quanto LIDs sem sufixo@lid(que também caem nessa faixa — 14-15 dígitos, mesma heurística já usada emnormalizePhone).Como a resolução é
.find()em ordem de posição do array de candidatos (remoteJidantes deremoteJidAlt, etc.), seremoteJidtrouxer o LID em dígitos nus eremoteJidAlttrouxer o telefone real, o LID vencia só por estar primeiro no array — não por ser mais confiável. Isso reabre, por uma rota diferente, o mesmo tipo de fragmentação de contato que o E35 fechou emnormalizePhone.Mudança
evolution-helpers.ts—resolveBestJidganha um tier extra: dígitos no formato LID (14-15 dígitos) são deixados para depois de@g.us, ao invés de competir na mesma prioridade que telefones reais (10-13 dígitos):Diff mínimo — só a função afetada, sem tocar
normalizePhone(já corrigido em #120) nemresolveEventJid(só repassa candidatos).Validação
tsc --noEmit: OKnode scripts/ci/lint-ratchet.mjs: 0 novas ocorrênciassupabase/deployment-manifest.json: regeneradovitest.contracts.config.ts: 167/167 passamnode --test scripts/ci/*.unit.mjs scripts/edge-deploy/*.unit.mjs: 38/38 passamnode scripts/db-audit/supabase-usage-guard.mjs: 0 violações novas🤖 Generated with Claude Code
https://claude.ai/code/session_018N9zUcTpab3dWsuR3ZSSBj
Summary by cubic
Updates
resolveBestJidto distinguish bare 14–15-digit LIDs from real phone numbers. Previously, both shared the same priority, so a LID inremoteJidcould beat a real phone inremoteJidAltbased only on candidate order; now 10–13-digit phones are preferred, while LID-length digits fall back after group JIDs to reduce contact fragmentation.Scope
resolveBestJidchanges behavior;normalizePhoneandresolveEventJidremain unchanged.supabase/deployment-manifest.jsonfor the updated helper source.Written for commit 16d3a5e. Summary will update on new commits.