Skip to content

fix(whatsapp): correct IQ-probe call shape; show pairing QR only when re-pairing helps - #119

Merged
retog merged 1 commit into
mainfrom
claude/gateway-connection-monitoring-fc52co
Aug 16, 2026
Merged

fix(whatsapp): correct IQ-probe call shape; show pairing QR only when re-pairing helps#119
retog merged 1 commit into
mainfrom
claude/gateway-connection-monitoring-fc52co

Conversation

@retog

@retog retog commented Aug 16, 2026

Copy link
Copy Markdown
Collaborator

Follow-up to #117 (merged), fixing a live regression it introduced plus the page defect the regression exposed — seen on a running deployment as a WhatsApp card stuck on "disconnected" with a broken QR image.

The probe bug (false "disconnected" on a healthy bridge)

The IQ probe from #117 passed the JID as a list, but current neonize takes it as varargs — the call died inside protobuf on every round:

Parameter to initialize message field must be dict or instance of same class:
expected <class 'Neonize_pb2.JID'> got <class 'list'>.

After two probe rounds a perfectly healthy bridge was reported as wedged: false connected: false on /gateways and a false monitor alert. The probe now:

  • tries both call shapes (scalar first — current bindings — then list for older ones),
  • treats call-shape errors (TypeError, the protobuf "Parameter to initialize message field" message) as "try the next convention", never as a wedge, while no shape has ever succeeded,
  • caches the working (method, shape) after the first success, so from then on every exception is a genuine probe failure (e.g. the real usync timeout),
  • disables itself (_IQProbeUnsupported, health falls back to link state) when no shape works at all.

The page defect (broken QR image)

/gateways offered a pairing QR for any disconnected gateway — but not every outage is fixed by scanning. An IQ wedge (or a Telegram transport drop) keeps the device linked, no QR PNG exists, GET /qr answers JSON, and the <img> rendered as a broken-image icon pointing the user at the wrong fix.

  • All three gateways now report needs_repair in /health: WhatsApp — only when unlinked/pairing (never for an IQ wedge); Telegram — only when the session is unauthorised; Signal — any sustained down state (signal-cli cannot distinguish an unlink from a transient failure, and its QR flow is an explicit user action anyway).
  • The page shows the QR block only when needs_repair is true (older gateways without the field keep the previous behaviour); otherwise it shows the error plus a note that the device is still paired and no scan is needed.
  • The QR <img> stays hidden until a refresh actually delivers an image (onload shows, onerror hides), so a still-generating code never renders as a broken icon.

Tests

tests/test_whatsapp_health.py grew three probe tests — call-shape discovery against the real protobuf error message, shape-error-everywhere → _IQProbeUnsupported (not a wedge), and a genuine usync timeout still raising — plus needs_repair assertions in the existing wedge/logged-out cases. Full suite passes locally except test_push_notify.py (fails on main too in this environment; broken system cryptography, unrelated).

After deploying, an affected gateway flips back to "connected" within one probe interval (≤ 1 min), clearing the false monitor alert.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YbqfmpARas38AfiwtCjZbn


Generated by Claude Code

… re-pairing helps

The IQ probe passed the JID as a list, but current neonize takes it as
varargs — the call died inside protobuf ("Parameter to initialize
message field must be dict or instance of same class: expected JID got
list") on every round, so a perfectly healthy bridge was reported as
wedged after two probes: a false "disconnected" on /gateways and a false
monitor alert. The probe now tries both call shapes (scalar first, list
for older bindings), treats shape errors as "try the next convention" —
never as a wedge — while no shape has ever succeeded, and caches the
working (method, shape) so later failures are always genuine probe
failures. If no shape works the probe disables itself and health falls
back to link state.

The false alarm also exposed a page defect: /gateways offered a pairing
QR for ANY disconnected gateway, but not every outage is fixed by
scanning — an IQ wedge (or a Telegram transport drop) keeps the device
linked, no QR exists, and the <img> rendered as a broken image. All
three gateways now report needs_repair in /health (WhatsApp: unlinked/
pairing; Telegram: session unauthorised; Signal: any sustained down
state, since signal-cli cannot distinguish), and the page shows the QR
block only then — otherwise it explains that the device is still paired.
The QR <img> also stays hidden until a refresh actually delivers an
image, so a still-generating code never renders as a broken icon.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YbqfmpARas38AfiwtCjZbn
@retog
retog merged commit ad5b3ee into main Aug 16, 2026
1 check passed
@retog
retog deleted the claude/gateway-connection-monitoring-fc52co branch August 16, 2026 19:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants