fix(avatares): o cron pede a foto pelo wa_lid antes do telefone - #737
fix(avatares): o cron pede a foto pelo wa_lid antes do telefone#737HigorLira wants to merge 1 commit into
Conversation
`wa_identity` é GERADA com o telefone antes do lid (migration 0122). Num
número BR cujo `wa_id` não tem o nono dígito — comum em linhas antigas —
derivar o chatId dela produz um endereço que não existe no WhatsApp: o
provider responde `profilePictureURL: null`, o cron carimba "sem foto" e
o avatar nunca aparece no Inbox.
Medido numa instalação real: para o mesmo contato, `check-exists`
devolveu `{"numberExists":true,"chatId":"<12 dígitos>@c.us"}` enquanto o
cron perguntava por `<13 dígitos>@c.us`; o `@lid` do mesmo contato
devolvia a foto na hora, e a linha em `contacts` já tinha o `wa_lid`.
A função local passa a seguir a MESMA ordem de `resolveWahaChatId`
(lib/waha/send.ts) e de `chatIdOf` (session-reconciler): wa_lid,
wa_identity, telefone. Fica local de propósito — importar de `lib/waha/`
acrescentaria menção de provider que a doutrina de canal desencoraja, e
`lint:channels` segue sem dívida nova.
O SELECT passa a trazer `wa_lid` e `phone_number`, que ele nem pedia.
|
@HigorLira is attempting to deploy a commit to the rafael-maudibrasil's projects Team on Vercel. A member of the Team first needs to authorize it. |
ECC Tools / Security EvidenceCommit: Security evidence gate passed (success) No security-sensitive scanner-evidence gap detected. Mode: enforce Scanned 2 changed file(s). No missing scanner-evidence signal was detected. Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
ECC Tools / PR Risk TaxonomyCommit: PR taxonomy review recommended (neutral) Detected 1 PR taxonomy bucket(s): CI/CD Recommendation. Scanned 2 changed file(s). Roadmap taxonomy buckets: CI/CD RecommendationCI, dependency, coverage, and contract signals should be routed into follow-up checks or verification work. Signals:
Paths:
Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
ECC Tools / Reference Set ReadinessCommit: Reference set readiness gaps detected (neutral) Reference evidence present for 0/7 areas (0%) across 2 changed file(s). This check is based on files changed in this PR. Repository-level readiness is still reported by
Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
|
Recebido, @HigorLira — obrigado por isto. Duas coisas que vão parecer erro seu e não são:
Um mantenedor vai revisar de verdade — rodando os gates e reproduzindo o comportamento, não só Esta mensagem é automática e não diz nada sobre o seu PR: ela é sobre o processo. O que vem |
ECC Tools / Hosted Promotion ReadinessCommit: Hosted promotion readiness passed (success) No hosted promotion evidence gaps detected across 2 changed file(s); 0 corpus scenarios had matching evidence. This check compares PR file changes against the evaluator/RAG promotion corpus in No evaluator corpus scenarios matched this PR. Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
1 participant
O que este PR faz
Faz a foto de perfil do contato aparecer no Inbox para números brasileiros cujo
wa_idnão tem o nono dígito — hoje ela nunca aparece, e o cron nem registra erro.Closes #728
O defeito
app/api/v1/cron/contact-avatars/route.tsmonta o chatId com uma função local que lê sówa_identity:wa_identityé gerada com o telefone antes do lid — o comentário dechatIdOf(session-reconciler) já nomeia isso como "o motivo da 0122". Em linha BR antiga, o telefone gravado tem 13 dígitos e owa_idreal tem 12. O endereço derivado não existe, o provider devolveprofilePictureURL: null, e o job cai no ramo que ele mesmo comenta como "contato sem foto ou com privacidade fechada: estado normal, não erro".O resultado é um defeito silencioso:
{"scanned":1,"updated":0,"no_picture":1,"failed":0}. Nada em log, nada emfailed.Medição em instalação real
Mesmo contato, mesma sessão, três identificadores:
contactIdenviado ao provider<13 dígitos>@c.us— o que o cron monta{"profilePictureURL": null}<12 dígitos>@c.us— owa_idreal<wa_lid>@lidE o próprio provider aponta o certo:
A linha em
contactsjá tinha owa_lidpreenchido. Era só não consultá-lo.Depois da correção, o mesmo cron no mesmo contato:
{"scanned":1,"updated":1,"no_picture":0,"failed":0}, com o arquivo gravado no bucket (37,7 KB,image/jpeg).A correção
A função local passa a seguir a mesma ordem de
resolveWahaChatId(lib/waha/send.ts) e dechatIdOf(session-reconciler.ts):wa_lid→wa_identity→ telefone. OSELECTpassa a trazerwa_lidephone_number, que ele nem pedia.Optei por manter a função local em vez de importar
resolveWahaChatId: o import acrescentaria menção de provider num arquivo que a doutrina de canal só tolera por ler a colunawaha_session_name.pnpm lint:channelssegue com "62 arquivos de dívida conhecida, nenhum novo".Teste
tests/unit/cron-contact-avatars-chatid.test.ts(novo, 3 casos): comwa_lidpede pelo@lid; sem ele cai nowa_identity;wa_identityno formatolid:também resolve para@lid.Verifiquei que ele pega o defeito — revertendo só o código, a asserção falha com a mensagem que descreve o bug:
Checklist (Definition of Done)
pnpm typecheckzeradopnpm lintzerado (0 errors; os 349 warnings são pré-existentes, nenhum nos arquivos tocados)pnpm lint:channelsok — nenhuma dívida novapnpm test:unit)console.logesquecido.changes/— não escrevi; sigo a orientação do template de que isso fica com vocêsSobre a suíte completa:
tests/unit/leads-import-route.test.tsfalha 11 testes namainsem este PR — confirmei comgit stash. Não mexi nesse caminho.