fix(whatsapp): correct IQ-probe call shape; show pairing QR only when re-pairing helps - #119
Merged
Merged
Conversation
… 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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
After two probe rounds a perfectly healthy bridge was reported as wedged: false
connected: falseon/gatewaysand a false monitor alert. The probe now:TypeError, the protobuf "Parameter to initialize message field" message) as "try the next convention", never as a wedge, while no shape has ever succeeded,(method, shape)after the first success, so from then on every exception is a genuine probe failure (e.g. the real usync timeout),_IQProbeUnsupported, health falls back to link state) when no shape works at all.The page defect (broken QR image)
/gatewaysoffered 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 /qranswers JSON, and the<img>rendered as a broken-image icon pointing the user at the wrong fix.needs_repairin/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).needs_repairis 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.<img>stays hidden until a refresh actually delivers an image (onloadshows,onerrorhides), so a still-generating code never renders as a broken icon.Tests
tests/test_whatsapp_health.pygrew 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 — plusneeds_repairassertions in the existing wedge/logged-out cases. Full suite passes locally excepttest_push_notify.py(fails onmaintoo in this environment; broken systemcryptography, 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