Summary
zlmdb.check_autobahn_flatbuffers_version_in_sync() (and the reciprocal
autobahn.check_zlmdb_flatbuffers_version_in_sync()) are meant to guard that the
FlatBuffers runtime vendored in zlmdb (data-at-rest) and in autobahn
(data-in-transit) are the same version — important for apps like Crossbar.io that
use both. But they compare the version() helper, which on the installed
packages returns an unstamped placeholder for both, so the check can never
detect a real mismatch and returns useless data.
See also: crossbario/zlmdb#122
Evidence
With zlmdb 26.6.1 + autobahn 26.6.2 (FlatBuffers vendored at v25.12.19 in both):
>>> import zlmdb, autobahn.flatbuffers, zlmdb.flatbuffers
>>> autobahn.flatbuffers.version() # used by the check
(0, 0, 0, None, None)
>>> zlmdb.flatbuffers.version() # used by the check
(0, 0, 0, None, None)
>>> autobahn.flatbuffers.__version__ # the meaningful value
'25.12.19'
>>> zlmdb.flatbuffers.__version__
'25.12.19'
>>> zlmdb.check_autobahn_flatbuffers_version_in_sync()
(0, 0, 0, None, None) # "in sync" - but only because both are 0,0,0
The current implementation (zlmdb):
def check_autobahn_flatbuffers_version_in_sync() -> str:
import autobahn.flatbuffers
zlmdb_version = flatbuffers.version()
autobahn_version = autobahn.flatbuffers.version()
if zlmdb_version != autobahn_version:
raise RuntimeError(...)
return zlmdb_version
Because version() returns (0, 0, 0, None, None) for both vendored copies, the
inequality is never true → the guard is a no-op: it would NOT catch a genuine
mismatch (e.g. zlmdb at v25.12.19 vs autobahn at v25.9.23, since both would still
report (0,0,0,None,None)), and it returns (0,0,0,None,None) instead of a
usable version string. The docstring even advertises returning a git version like
"v25.9.23-2-g95053e6a", which does not match the actual behavior.
Suggested fix
Compare the __version__ strings (which are correctly stamped to the vendored
git tag, e.g. "25.12.19") instead of version():
def check_autobahn_flatbuffers_version_in_sync() -> str:
import autobahn.flatbuffers
zlmdb_version = flatbuffers.__version__
autobahn_version = autobahn.flatbuffers.__version__
if zlmdb_version != autobahn_version:
raise RuntimeError(
f"FlatBuffers version mismatch: zlmdb has {zlmdb_version!r}, "
f"autobahn has {autobahn_version!r} ..."
)
return zlmdb_version
Apply the same fix to autobahn's reciprocal
check_zlmdb_flatbuffers_version_in_sync().
Alternatively, if version() is intended to be the authoritative source, ensure
it is actually stamped at build/vendor time (it currently returns
(0, 0, 0, None, None)), and update the docstring accordingly.
Tests
Add a unit test that the check returns the expected version when in sync, and
raises when the two __version__ values differ (monkeypatch one) — the
current test, if any, passes vacuously because both sides are (0,0,0,...).
Context
Found while improving crossbar version to report both vendored FlatBuffers
versions (crossbar #2156). Crossbar now compares __version__ directly for its
display rather than relying on this helper, but the helper itself should be fixed
since it is the documented cross-project guard.
Note: This work was completed with AI assistance (Claude Code). Initiated and reviewed by me.
Checklist
Summary
zlmdb.check_autobahn_flatbuffers_version_in_sync()(and the reciprocalautobahn.check_zlmdb_flatbuffers_version_in_sync()) are meant to guard that theFlatBuffers runtime vendored in zlmdb (data-at-rest) and in autobahn
(data-in-transit) are the same version — important for apps like Crossbar.io that
use both. But they compare the
version()helper, which on the installedpackages returns an unstamped placeholder for both, so the check can never
detect a real mismatch and returns useless data.
See also: crossbario/zlmdb#122
Evidence
With zlmdb 26.6.1 + autobahn 26.6.2 (FlatBuffers vendored at v25.12.19 in both):
The current implementation (zlmdb):
Because
version()returns(0, 0, 0, None, None)for both vendored copies, theinequality is never true → the guard is a no-op: it would NOT catch a genuine
mismatch (e.g. zlmdb at v25.12.19 vs autobahn at v25.9.23, since both would still
report
(0,0,0,None,None)), and it returns(0,0,0,None,None)instead of ausable version string. The docstring even advertises returning a git version like
"v25.9.23-2-g95053e6a", which does not match the actual behavior.Suggested fix
Compare the
__version__strings (which are correctly stamped to the vendoredgit tag, e.g.
"25.12.19") instead ofversion():Apply the same fix to autobahn's reciprocal
check_zlmdb_flatbuffers_version_in_sync().Alternatively, if
version()is intended to be the authoritative source, ensureit is actually stamped at build/vendor time (it currently returns
(0, 0, 0, None, None)), and update the docstring accordingly.Tests
Add a unit test that the check returns the expected version when in sync, and
raises when the two
__version__values differ (monkeypatch one) — thecurrent test, if any, passes vacuously because both sides are
(0,0,0,...).Context
Found while improving
crossbar versionto report both vendored FlatBuffersversions (crossbar #2156). Crossbar now compares
__version__directly for itsdisplay rather than relying on this helper, but the helper itself should be fixed
since it is the documented cross-project guard.
Note: This work was completed with AI assistance (Claude Code). Initiated and reviewed by me.
Checklist