mirror of
https://github.com/TheGrandWazoo/freenas-proxmox.git
synced 2026-09-30 03:51:27 +02:00
Kevin AdamsandClaude Sonnet 5
d2d20c339a
AnyEvent::WebSocket::Client's blocking ->recv() cannot run inside pveproxy/pvedaemon (themselves built on AnyEvent as their core reactor) without nesting event loops, which AnyEvent refuses by design -- confirmed by a real user on the first real WebUI use of v4.0.0, one day after release. Not a race condition: this fails on every real "Add Storage" attempt against a WebSocket-transport host, unconditionally. v4.0.0's testing never caught it because every verification script ran standalone, never inside the actual daemon process -- pvesm (a fresh CLI process) doesn't trigger it either, only the real REST API path through pveproxy does. Replaced _ws_connect/_ws_call's internals with Protocol::WebSocket::Client + IO::Socket::SSL -- a plain synchronous socket client with zero event-loop dependency, so there's no shared reactor state to conflict with pveproxy's. _api_ws's method-mapping logic is completely unchanged; only the connection/call internals were rewritten. Reproduced the exact bug via a real POST to /api2/json/storage through pveproxy on a lab node, then confirmed the fix resolves it the same way. Re-ran every check from v4.0.0's release (read path, write path, snapshots, multipath) against the new transport -- zero regressions. Full story: ADR-014, superseding ADR-012's library-choice section only (everything else in ADR-012 stands). $VERSION bumped to 4.0.1. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>