rmyndharis/OpenWA v0.8.8

on GitHub

Added

• Native WhatsApp polls via POST /api/sessions/:sessionId/messages/send-poll: question, 2–12 options and an optional allowMultipleAnswers flag (default single choice), implemented on both engines (whatsapp-web.js Poll, Baileys poll content with selectableCount 1/0). The message history stores the poll question as the body so the log stays readable. Polls are a first-class poll message type end to end — both engines map incoming poll messages to it, so the websocket/webhook events, persisted rows, and dashboard all report poll consistently. Thanks @alejo117.

Changed

• Corrected the Italian login-footer wording. Thanks @albanobattistella.

Fixed

• GET /api/sessions/:sessionId/channels/:channelId/messages always returned an empty array on the whatsapp-web.js engine (#625). The adapter called client.getChannelById(), which does not exist in whatsapp-web.js 1.34.x, so every call threw and the error was swallowed into []. Channel messages are now read from the subscribed Channel instance (via getChannels()), and an unknown/unsubscribed channel returns a 404 (ChannelNotFoundError) instead of a silent empty 200 — matching GET /channels/:channelId. Thanks @Header9968.
• A session whose engine.initialize() fails no longer orphans its browser process. The crash-recovery path in SessionService.start() was tearing down the half-built engine with a graceful destroy(), but a failed initialize() usually means the underlying browser/CDP connection is already broken (e.g. a TargetCloseError: Target closed mid-injection) — destroy() has nothing live to talk to, so it could only time out after 10s via teardownEngineSafely's race, leaving the Chromium process alive and orphaned. Every such crash left one more orphaned process behind, eventually starving the host of memory. It now uses forceDestroy() (the same SIGKILL-the-process recovery POST /:id/force-kill uses), since a failed initialize is the same "possibly-unreachable engine" state that exists for.
• Authenticated HTTP/HTTPS proxies now work on the whatsapp-web.js engine (#628). Credentials were passed inside --proxy-server, which Chromium ignores, so a proxy with a username/password never authenticated (only IP-authorized proxies worked). The username/password are now handed to whatsapp-web.js's proxyAuthentication (which drives Chromium's page.authenticate) while --proxy-server gets a credential-less URL. SOCKS proxies still cannot be authenticated — Chromium does not support SOCKS proxy authentication at all — so a SOCKS proxy carrying credentials now logs a clear warning instead of failing with an opaque navigation timeout. Thanks @gudge25.