658ab7f6e7
Tests · FBS codegen / codegen (push) Successful in 5s
Tests · Go / test (push) Successful in 2m29s
Tests · FBS codegen / codegen (pull_request) Successful in 6s
Tests · UI / test (push) Waiting to run
Tests · Integration / integration (pull_request) Successful in 1m46s
Tests · Go / test (pull_request) Successful in 3m20s
Tests · UI / test (pull_request) Successful in 3m19s
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.
40 lines
1.6 KiB
Markdown
40 lines
1.6 KiB
Markdown
# 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`:
|
|
|
|
```shell
|
|
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:
|
|
|
|
```shell
|
|
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.
|