bazelbuild/bazel

Changing the schema for lockfile facts is hard to do safely

Open

#29483 opened on May 6, 2026

View on GitHub
 (4 comments) (0 reactions) (0 assignees)Java (25,384 stars) (4,465 forks)batch import
P2help wantedteam-ExternalDepstype: bug

Description

Description of the bug:

I'm using lockfile facts heavily for rules_rs and I realized I can change the encoding a bit to help mitigate the lockfile size explosion (related to https://github.com/bazelbuild/bazel/issues/29446). However, it's not clear to me how to do this safely without breaking users. I can certainly write new code to read/write the new format and even gracefully handle the old format + rewrite to new one. But I can't go back in time and make the old code do something reasonable with the new format, which means if a downstream user tries a rules_rs upgrade on a branch (which rewrites their lockfile) and then swaps back to their main branch on the older ruleset version, their previous rules_rs version will fail to parse the new lockfile.

The only idea i've come up with is to use brand-new key names for all facts, but the key names were fairly canonical (the facts about crate foo at version x.y were keyed by foo-x.y). We could do something like append a -v2 suffix to the keynames but that doesn't feel great given the purpose of the change is to minimize bytes used.

See https://bazelbuild.slack.com/archives/C014RARENH0/p1778087918441709 for a bit of discussion

Which category does this issue belong to?

No response

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

No response

Which operating system are you running Bazel on?

No response

What is the output of bazel info release?

No response

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

Contributor guide

Tech stack
java
Domain
build systeminfrastructure
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
5
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
over 1 week
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
fresh
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
needs investigation
Prerequisites
Bazel internalslockfile factsschema migration
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
5
Research direction
Investigate the existing Bazel lockfile facts format and understand the size explosion problem referenced in issue #29446. Consider a versioning scheme for key names (e.g., appending a version suffix) or a new format that can be read by both old and new code with graceful degradation. Look at the Slack discussion (C014RARENH0) for additional context. Design a migration strategy that ensures forward/backward compatibility without breaking users who switch between branches with different rules rs versions.