Marc-André Bombeck 2f3da10317 Ask the newest values before the key check refuses ...

The probe decided on the eight oldest values alone. An install
reinstalled under a fresh key long ago holds old rows sealed under a key
that is gone and all current data under the key it runs with; it works
today, and the check would refuse it with 503 on every request.

When every oldest value fails, the newest values of the same columns are
now sampled in reverse order. One that opens makes the verdict
inconclusive (mixed): the process serves, warns and probes again at the
next start. Only old and newest values that all fail are a mismatch. A
newest-only open never seals; sealing stays with the oldest-first rule.

Every probe query now runs in its own transaction under a
transaction-local statement_timeout (2 s), so a large or locked table
ends that column with an error and the probe as incomplete instead of
holding up the boot. The newest order is the exact mirror of the oldest,
so an index on the timestamp serves both directions.

The module comment lists the three conditions that still yield a
mismatch.

2026-10-04 01:58:04 +02:00

..

fixtures/v137

Merge remote-tracking branch 'origin/main' into wip/v140-H

2026-10-03 22:52:49 +02:00

integration

Ask the newest values before the key check refuses

2026-10-04 01:58:04 +02:00