Problem
When the standalone server (python -m buckaroo.server) and the buckaroo-js-core renderer run at incompatible versions, the grid renders empty: rows ship over the WebSocket but the client mis-decodes the window, and nothing — server log, WS message, or UI — says why. It looks like a data or recipe problem; it is a version skew.
Concretely: a server bumped 0.15.1 → 0.15.3 against a renderer pinned 0.14.8 (and a stale 0.12.0 actually installed). 0.15.2's #938 changed the row-cell parquet transport (native parquet strings, json_columns), so an older renderer decodes the window into nothing and shows zero rows over a session that /load_expr reported with the full rows= count. The wire format changed in #938 but the handshake still advertises protocol_version: 1, so there is no field a client can currently check to detect the mismatch.
Suggested fix
On connect (the /load_expr response and/or the WS handshake) advertise a transport/protocol version, and have the renderer surface a loud, visible error ("server X vs renderer Y: incompatible") instead of an empty grid. Bumping protocol_version whenever the wire format changes (as in #938) would give that check something to compare against.
This only bites in the standalone/embedded-server path; in the Jupyter/Marimo widget both halves ship from one wheel and cannot drift, so scoping the check there is reasonable. That is a buckaroo call.
Context
Found integrating buckaroo's standalone server into an external React app (tallyman): a server-only bump silently blanked every grid while the data was present server-side the whole time. Worked around downstream with a version-lockstep test that pins the Python buckaroo and npm buckaroo-js-core versions to match.
Problem
When the standalone server (
python -m buckaroo.server) and thebuckaroo-js-corerenderer run at incompatible versions, the grid renders empty: rows ship over the WebSocket but the client mis-decodes the window, and nothing — server log, WS message, or UI — says why. It looks like a data or recipe problem; it is a version skew.Concretely: a server bumped 0.15.1 → 0.15.3 against a renderer pinned 0.14.8 (and a stale 0.12.0 actually installed). 0.15.2's #938 changed the row-cell parquet transport (native parquet strings,
json_columns), so an older renderer decodes the window into nothing and shows zero rows over a session that/load_exprreported with the fullrows=count. The wire format changed in #938 but the handshake still advertisesprotocol_version: 1, so there is no field a client can currently check to detect the mismatch.Suggested fix
On connect (the
/load_exprresponse and/or the WS handshake) advertise a transport/protocol version, and have the renderer surface a loud, visible error ("server X vs renderer Y: incompatible") instead of an empty grid. Bumpingprotocol_versionwhenever the wire format changes (as in #938) would give that check something to compare against.This only bites in the standalone/embedded-server path; in the Jupyter/Marimo widget both halves ship from one wheel and cannot drift, so scoping the check there is reasonable. That is a buckaroo call.
Context
Found integrating buckaroo's standalone server into an external React app (tallyman): a server-only bump silently blanked every grid while the data was present server-side the whole time. Worked around downstream with a version-lockstep test that pins the Python
buckarooand npmbuckaroo-js-coreversions to match.