Claim a library for a branch, not for a configuration

[adrpo]

Two machines testing master at the same time still claimed five of the same libraries and tested them twice:

      libname       |     host      | confighash
--------------------+---------------+------------
 Modelica_trunk     | ryzen-5950x-1 | 2000484329
 Modelica_trunk     | ryzen-5950x-2 |  144973828
 Modelica_4.1.0     | ryzen-5950x-1 | 3446674171
 Modelica_4.1.0     | ryzen-5950x-2 |  177846189
 ModelicaTest_trunk | ...

Same compiler, same library version — a different confighash, which is part of the claim key.

#303 fixed a confighash that differed for no reason (it contained an absolute path). These five differ for a real reason. They are exactly 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+build.4, which do not move, agreed on 91 of 96 claims.

So the configurations genuinely differed — and the claim was keyed by the configuration:

PRIMARY KEY (branch, libname, libversion, omcversion, confighash)

That is finer than the question a claim answers. There are three questions here, and only two of them are about the configuration:

question	key
is a machine testing this library right now?	(branch, libname)
do we already have results for this exact configuration?	+ libversion, omcversion, confighash
can two runs' rows collide?	(date, libname, model)

The second and third are unchanged. Only the claim is narrowed, to one row per (branch, libname). The versions stay as columns so a run can still report who is testing what, and since when.

Migrating

An existing job_claim is narrowed when a run connects, keeping the freshest claim per library rather than dropping the table — otherwise migrating would release the claims of a run in progress and let a second machine straight in.

Checked

Against a database seeded to look like production, with a live claim in the old five-column shape:

Narrowing job_claim from (branch, libname, libversion, omcversion, confighash) to (branch, libname)
  the live claim survived the migration                    ok
  the key is now (branch, libname)                         ok
  second machine refused despite a different confighash    ok
  it is told who holds it                                  ok
  a library nobody holds is granted                        ok
  and then refused to the first machine                    ok
  after release the other machine may take it              ok
  no library is claimed by two machines                    ok

plus a sqlite3 run through the CI configuration with its assertion, and a PostgreSQL run with two FMI simulators that releases its claim as done.

Worth knowing separately

The two machines are currently comparing against different v4.1.0 reference files. That is not only a claiming problem: the same model can pass on one machine and fail on the other for that reason alone, and a regression report pairing those two runs would show differences that are not OpenModelica's doing.

---

Generated by Claude Code.