build(deps): update flatbuffers requirement from 24.12.23 to 25.12.19 - #115
build(deps): update flatbuffers requirement from 24.12.23 to 25.12.19#115dependabot[bot] wants to merge 1 commit into
Conversation
…mpiler (#125) * build: fail CI when the flatbuffers runtime drifts from the pinned compiler Closes the residual #110 documented but did not fix. Everything in the drift job compared generated code to the SCHEMAS; nothing compared it to the RUNTIME, so bumping `flatbuffers` in Cargo.toml while leaving PINNED_FLATC alone passed every check. Not hypothetical: PR #115 (flatbuffers 24.3 -> 25.12) is open and green on exactly this job. It would leave the bindings generated by flatc 24.12.23 while the crate they compile against is 25.12.19 -- upstream ships the compiler and the runtime from one tag, and generated code is only guaranteed against the runtime it was generated for, so a pin on one alone is half a pin. The job now reads what `flatbuffers` actually RESOLVED to rather than what the manifest asked for, since Cargo.lock is untracked and the requirement is a range, and fails on a mismatch naming both versions and both ways to fix it. Verified both directions: it reports 24.12.23 against the current pin and passes; with Cargo.toml moved to "25.12" the resolved version becomes 25.12.19 and the check fails. That is the #115 scenario, which will now fail honestly instead of merging silently. No spurious-failure risk from upstream: 24.12.23 is the last 24.x release (everything since is 25.x), so the caret range cannot drift on its own. The check catches a human changing one pin without the other, which is the case that actually happens. Also corrects the PINNED_FLATC doc comment, which described this as undetected. Claude-Session: https://claude.ai/code/session_01D2yvFcLd56ZaeoRi4mojcD * build: enforce the runtime pin for consumers too, and resolve only our own dependency Both from external review of this PR. The check as written validated only CI's own resolution, so it did not enforce the invariant it claimed. `flatbuffers = "24.3"` admits any 24.x, including releases OLDER than the compiler the bindings were generated with, and a consumer whose workspace already resolved 24.3.25 would have compiled 24.12.23-generated bindings against a runtime they were not generated for. My "24.12.23 is the last 24.x" argument covered drift upward and missed drift downward entirely. The manifest floor is now the pinned release. The caret still permits a later 24.x, so this is not an `=` pin and cannot make a consumer's graph unsatisfiable, but since 24.12.23 is the last 24.x the range is a single point in practice -- for consumers, not just for CI. The extraction also selected every package named flatbuffers and compared the joined list against one version, so a second flatbuffers anywhere in the graph (a dev dependency, another workspace member) would have failed the job even with our own runtime correct. It now walks the resolve graph from freenet-stdlib to its direct dependency. Verified after both changes: the pin resolves to 24.12.23 and the check passes; with the manifest moved to "25.12" it resolves to 25.12.19 and fails. The script exits with a message rather than empty output, and a failure anywhere in the pipeline aborts the step under `bash -e`, so there is no path where an unset value compares equal and passes. Claude-Session: https://claude.ai/code/session_01D2yvFcLd56ZaeoRi4mojcD * build: scope the runtime check honestly and stop overclaiming what it guarantees From review. Two of these are wording, and the wording was the problem: the change as written left the repo believing more was guaranteed than is. The comment asserted that compiler and runtime "have to be the same release" as a general rule, while checking only Rust. That rule is contradicted by this repo: the npm runtime is ^25.9.23, two majors ahead of the same pinned compiler that generates typescript/src, and its suite passes. So either the TypeScript side was a live defect this change walked past, or the premise was overstated -- and the passing suite says it is the premise. The step is now named for Rust, and says plainly that cross-major mixing is evidently not fatal in practice, that this guards the half we control end to end, and that aligning TypeScript means moving PINNED_FLATC to 25.x and regenerating both languages as a deliberate change. The build.rs doc claimed "CI enforces that" while the module doc thirty lines above says the job is advisory until it is added to branch protection, which `main` does not require. Two statements in one file, one of them false. It now says reports. Also: `set -o pipefail`, because the assignment was fail-closed only by virtue of python rejecting empty input -- an extractor that tolerated it would have degraded silently, and this job already uses `|| true` deliberately elsewhere. The resolve walk now ignores dev-only dependency kinds and reports a multi-version resolution as its own error rather than as a confusing mismatch. And the PINNED_FLATC doc carries the full bump checklist, since FLATC_SHA256 lives in another file and cannot be derived. Verified: extraction still returns 24.12.23, the pipeline aborts on a failed upstream command under pipefail, and the workflow YAML parses. Claude-Session: https://claude.ai/code/session_01D2yvFcLd56ZaeoRi4mojcD
|
Heads up: this will now fail CI, deliberately, and the failure is correct. #125 added a check that the resolved Until #125 this PR was green on every check, which was the gap: the drift job compares generated code to the schemas and never to the runtime. To land this properly it needs to be a coordinated bump, in one commit:
Step 4 will produce a large diff — 25.x formats its output differently from 24.x — which is expected and is why the compiler is pinned at all. Worth noting this bump is probably the right direction eventually: [AI-assisted - Claude] |
8961981 to
b12ad34
Compare
Updates the requirements on [flatbuffers](https://github.com/google/flatbuffers) to permit the latest version. - [Release notes](https://github.com/google/flatbuffers/releases) - [Changelog](https://github.com/google/flatbuffers/blob/master/CHANGELOG.md) - [Commits](google/flatbuffers@v24.12.23...v25.12.19) --- updated-dependencies: - dependency-name: flatbuffers dependency-version: 25.12.19 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
b12ad34 to
2794a44
Compare
Updates the requirements on flatbuffers to permit the latest version.
Release notes
Sourced from flatbuffers's releases.
... (truncated)
Changelog
Sourced from flatbuffers's changelog.
... (truncated)
Commits
7e16302FlatBuffers Version 25.12.19 (#8871)57fdd4fDefault Vector Support C++ (#8870)8cb53ccAdd --gen-absl-hash option to generate AbslHashValue for structs. (#8868)fb55e0cRun clang-format -i **/*.cpp (#8865)d9fde67Remove progaurd-rules.pro (#8866)f74fda2Update CODEOWNERS15802faCreate CODEOWNERSa86afaeFix casing in generated Kotlin struct constructor function (#8849)60910fbFix nullability of generated Kotlin ByteBuffer accessors (#8844)7bfaabc[TS] Flexbuffers root vector fix (#8847)