Ilia Denisov
658ab7f6e7
The committed FlatBuffers bindings were generated by flatc 25.x (the TS runtime is flatbuffers@25.9.23), but nothing pinned the compiler, so a regen on a box with an older flatc (Debian apt ships 23.5.26) silently churns output and flips nullable-scalar builder defaults. PR #82 hit this and shipped 5 report files from the wrong compiler. Unify the whole toolchain on 25.9.23 (the only version available as an npm package, a prebuilt flatc binary, and a Go tag) and make the bindings reproducible: - Downgrade the flatbuffers Go module 25.12.19 -> 25.9.23 (schema, transcoder, gateway, integration) so compiler and both runtimes match. - Regenerate every schema with flatc 25.9.23. The only resulting change is order/command-item.ts: the lone straggler still on the old optional-scalar builder default (cmd_applied/cmd_error_code: 0 -> null). Inert in practice — the TS side never builds those response-only fields (the engine sets them in Go); the reader is unchanged. - Pin the version in tooling: a flatc-check guard in ui/Makefile (fbs-ts) and a new pkg/schema/fbs/Makefile (fbs-go); both refuse a mismatched flatc and point at the release binary. Fix the stale apt install hint. - Add a path-filtered CI guard (.gitea/workflows/fbs-codegen.yaml) that regenerates with the pinned flatc and fails on any diff. - Document the pinned version and the regen commands in the schema README. No wire-format change: Go build/vet, transcoder roundtrip + engine tests, pnpm check and the full vitest suite (888) stay green.
Flatbuffers schemas
Pinned flatc version
The committed bindings — Go under <schema>/ and TS under
ui/frontend/src/proto/galaxy/fbs/ — and the flatbuffers runtimes
(github.com/google/flatbuffers in the Go modules, flatbuffers in
ui/frontend/package.json) are all on flatc 25.9.23. Regenerate
only with that exact version: a different flatc silently churns output
and can flip nullable-scalar wire defaults (= null builder slots
switch between the presence-preserving null form and the value-omitting
0 form). The fbs-go / fbs-ts targets refuse to run on a mismatch,
and the fbs-codegen CI workflow fails if the committed bindings differ
from a pinned-flatc regeneration.
Distro packages are too old (e.g. Debian trixie ships flatbuffers-compiler
23.5.26). Install the pinned binary from the release page:
https://github.com/google/flatbuffers/releases/tag/v25.9.23.
Generating sources
Regenerate both sides with the pinned flatc on PATH:
make -C pkg/schema/fbs fbs-go # Go bindings into pkg/schema/fbs/<schema>/
make -C ui fbs-ts # TS bindings into ui/frontend/src/proto/galaxy/fbs/
fbs-go runs, for every schema in this directory:
flatc --go --go-module-name galaxy/schema/fbs {file}.fbs
The --go-module-name flag rewrites cross-namespace imports to the
fully-qualified module path (e.g. common "galaxy/schema/fbs/common")
so the generated code links inside this Go module without local
replace directives. Omitting the flag yields imports such as
common "common" which fail to resolve.