[ropu]

Problem and behavior

On a real GOWS session (WAHA 2026.8.2), sending directly to 5411XXXXXXXX@c.us failed with HTTP 500 (no LID found), even though checkNumberStatus resolved that phone to the canonical 54911XXXXXXXX@c.us PN and a LID. Passing the canonical PN to sendText succeeded and received a DEVICE acknowledgement.

Integrations may supply Argentine destinations as 54 + national number or 549 + national number. This adds an opt-in argentine-phone-numbers app that resolves the supplied phone through checkNumberStatus before sending. It tries the other form only after WhatsApp explicitly reports that the original does not exist, then sends once to the returned PN/JID or LID.

For example, if 5411XXXXXXXX is absent and 54911XXXXXXXX resolves, the send uses the returned identifier. If the original exists, it wins. Both forms may resolve independently: cache entries and concurrent lookups are keyed by the original input, not the candidate pair.

This follows the apps/session-plugin direction described in #2180. It uses existing hooks and engine interfaces; there are no engine changes or new HTTP endpoints.

Scope

• International geographic Argentine numbers, including area codes beyond Buenos Aires; optional +, @c.us and @s.whatsapp.net.
• Per-session app, disabled unless installed/enabled, with lookup, strict and memoryTtl configuration.
• Successful in-memory cache (24h default), brief confirmed-negative cache, and deduplicated lookups per input. No database migration or persistent cache in this first version.
• Timeouts and incomplete lookup answers preserve the original destination and are not cached. Strict mode returns 422 only after both candidates explicitly report absence.
• Message-send chat targets only. No changes to mentions, incoming identifiers, call rejection, deletion, read/presence or group administration. The allowlist also prevents recursive WPP lookups.
• No inference from local 011/15 forms or missing country codes, and no alternate-contact shortcut that would bypass checking the original.

Configuration and a reproducible live validation procedure are in src/apps/argentine-phone-numbers/README.md.

Validation

• yarn test:unit --runInBand argentine-phone-numbers: 47 passed. Includes real hook registration, native JID conversion, recursive lookup prevention, separate accounts/caches, concurrent queries, LIDs, expiry without background timers, negative results and transient failures.
• yarn tsc --noEmit: passed.
• Scoped yarn oxlint --deny-warnings: passed.
• yarn build: passed.
• Brazilian regression suites: 26 failed / 19 passed. Reproduced the same 26 failures in a clean worktree at upstream 92c7923c35cbb8e5975f30fec66440b571c2c12f: test sessions omit media.events, and two repository date tests fail. These files are unchanged.
• Docker (Linux ARM64 / Node 24): docker buildx build --target build --output type=cacheonly . passed on the final code. The complete build stage was rebuilt; no runtime image was exported or deployed. An earlier image-export attempt was canceled after compilation while exporting layers.

Live validation — 2026-09-10

Tested the compiled plugin at 51c0039 with real SessionHooks / RegisterPluginHooks, using a remote API adapter to a paired WAHA 2026.8.2 Core / GOWS session (Linux x64). The resolved destination was sent through that same session's sendText endpoint. The running worker was not changed or restarted: this exercises resolver integration with real WhatsApp lookup and delivery, not installation/lifecycle of the app inside the worker.

Case	Observed result
checkNumberStatus with/without 9	Both returned the same LID and canonical 54911…@c.us PN
Direct send without plugin to 5411…@c.us	HTTP 500: no LID found for 5411…@s.whatsapp.net from server
Plugin resolves input without 9, then sends	HTTP 201; retrieved message reports ack=2, ackName=DEVICE
Plugin resolves input with 9, then sends	HTTP 201; retrieved message reports ack=2, ackName=DEVICE
Repeat resolution of the same input	Cache hit, no additional lookup

Two test messages reached the explicitly authorized recipient's device. All personal/session identifiers and raw responses are omitted from the PR. The README records the redacted evidence and procedure.

This recipient exercises canonicalization of a positive lookup, not the alternate-candidate fallback after absence. The fallback is unit-tested. No live WEBJS/NOWEB/WPP delivery coverage or installed-app lifecycle validation is claimed.

[devlikepro]

Let's try dev image 🤞🏻

Make sure to select the engine via the environment variable - WHATSAPP_DEFAULT_ENGINE=WEBJS|GOWS|NOWEB:

• devlikeapro/waha:dev
• devlikeapro/waha:dev-chrome
• devlikeapro/waha:dev-arm

🚀 Will be included in the next release!

[ropu]

Thanks for integrating this! I confirmed that 3ac4ab0 includes the Argentine app in the shared phone-number framework and references this PR.

I pulled devlikeapro/waha:dev-arm (image revision aa0663b1870e384e392d828b8cdf4470ac70eb74, digest sha256:92563df5d930c7d0e137f41dc7d5886ffb54bdf5310f78b14b85550258713ff7) and ran the packaged Argentine plugin and rules tests in an isolated container: 2 suites, 19 tests passed.

These were the shipped component tests with mocked lookups; I did not rerun live WhatsApp delivery or deploy the dev image to our worker. The earlier live GOWS delivery results remain documented in the PR.

Since the functionality is already implemented in dev, I am closing this original PR as superseded by your implementation rather than updating the conflicting duplicate. Thanks!

[devlikepro]

• 2026.9.1 - Phone Numbers - resolve numbers to the WhatsApp chatId before sending, with optional regexp rules (^52(\d{10})$ => 521$1)
• 2026.9.1 - Phone Numbers: Argentina - resolve numbers with or without the mobile 9 (54... / 549...) - #2260
• 2026.9.1 - Phone Numbers: Mexico - resolve numbers with or without the old 1 after the country code (52... / 521...)