Make the configuration hash the same on every machine - #303
Merged
Conversation
Two machines testing the same library, with the same compiler and the same library version, claimed it both and tested it both. The claim in #295 is keyed by (branch, libname, libversion, omcversion, confighash), and their confighashes differed, so as far as the database was concerned they were testing different things. The hash is taken over the configuration of the library, and the configuration by then holds the reference files as an absolute path: destinationReal = os.path.realpath(destination) c["referenceFiles"] = destinationReal so two machines whose workspaces sit in different places, or whose paths pass through different symbolic links, hash the same configuration differently. That never mattered while each machine had its own sqlite3 file and the hash only had to be stable on the machine that made it. Sharing one database made it matter, and it defeats both the claim and the check for results we already have. The path says nothing that the hash needs: the contents of the reference files are hashed right after it, and the same files in another directory are the same test. It is replaced by a constant. Checked with the same configuration under two different reference directories: the hashes were 3181697168 and 2732211752 before, are equal after, and still differ when a reference file itself changes. Every confighash changes value once, so the first run after this treats every library as untested and tests it. From then on the machines agree. --- Generated by Claude Code.
adrpo
added a commit
that referenced
this pull request
Aug 11, 2026
Two machines testing master both claimed five of the same libraries and tested them twice. #303 fixed the confighash being different for no reason; these five differ for a real one. They are the libraries whose reference files come from MAP-LIB_ReferenceResults/v4.1.0, which a maintenance job updates from time to time, and the two machines had fetched them either side of such an update. The libraries pinned to v4.0.0 and v3.2.3, which do not move, agreed. So the configuration really did differ, and the claim was keyed by it: PRIMARY KEY (branch, libname, libversion, omcversion, confighash) which is finer than the question a claim answers. Whether this machine may test this library of this branch has nothing to do with which reference files it has; that belongs to the two questions that are keyed by the configuration and stay as they are - whether results for an exact configuration already exist, and whether two runs' rows can collide. The claim is now one row per (branch, libname). The versions are kept as columns, so a run still says who is testing what and since when. An existing job_claim is narrowed on connect, keeping the freshest claim per library so that a run in progress does not lose its claims and let a second machine in. Checked against a database seeded the way production looks: the live claim survives the migration, the key becomes (branch, libname), a second machine with a different confighash is refused and told who holds it, a free library is granted and then refused to the first machine, and after release the other machine may take it. Plus a sqlite3 run through the CI configuration and a PostgreSQL run with two FMI simulators. --- Generated by Claude Code.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two machines running
masterat the same time both claimed the same 20 libraries and tested them twice, which is what #295 exists to prevent:Not the compiler and not the library: both machines report
OMCompiler v1.28.0-dev.294+gce7a5ed7bcand the samelibversion(there had been no omc commit for seven hours). What differed was the confighash, which is part of the claim key(branch, libname, libversion, omcversion, confighash):Why
The hash is taken over the library's configuration, and by that point the configuration holds the reference files as an absolute path:
So two machines whose workspaces sit in different places — or whose paths resolve through different symbolic links — hash an identical configuration differently.
This was harmless for as long as it existed: each machine had its own
sqlite3.db, so the hash only ever had to be stable on the machine that produced it. Sharing one database is what made it matter, and it breaks two things at once:The fix
The path contributes nothing the hash needs. The contents of the reference files are hashed on the very next line by
hashReferenceFiles(), and the same files in a different directory are the same test. So the path is replaced by a constant before hashing.Checked
The same configuration under two different reference directories:
so the hash stops depending on where the files are while still depending on what is in them. Plus a full
configs/sanityCheck.jsonrun with the CI assertion passing.One deliberate consequence
Every
confighashchanges value once. The first run after this sees no matching rows and treats every library as untested, so it tests everything once. From then on the machines agree — and until then they duplicate work anyway, which is the bug.Generated by Claude Code.