Paul HittandClaude Opus 5
625b4516c7
I pinned the vector clone earlier today on flamenet-relay#56's evidence, and stopped a step short. flamenet-relay did not: it pins AND keeps `conformance-head` / `doc-pages-head` running against HEAD with `allow_failure: true`, and its `.e2e-ref.md` says why in a sentence I had read and not acted on — "a relay tested against a pinned old harness is tested against a pinned old spec, and that argument still holds." A pin alone is worse than HEAD for exactly that reason. HEAD couples this board to another repository's merges; a bare pin means the vectors can move and this suite goes on checking last month's protocol, reporting green, with nothing anywhere saying so. The first failure is loud and wrong; the second is quiet and wrong, and quiet is worse in a conformance suite whose whole job is to notice a divergence. So: `.e2e-ref` holds the commit, `unit-tests` checks against it and blocks, and `vectors-head` runs the same vector suites against HEAD and is allowed to fail. Being behind is loud and non-blocking. Being broken is still a hard stop. Verified it would actually notice, rather than assuming — pin and HEAD are the same commit today, so a green advisory run proves nothing. With one expected value in `account-kdf-v1.json` mutated, `AccountKdfTest` reddens. `.e2e-ref.md` records the procedure and the deadlock story behind it. ⚠️ `vectors-head` runs `:engine:test` only. The rest of the suite has nothing to say about whether flamenet-e2e moved. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1.6 KiB
Why this repository pins flamenet-e2e
.e2e-ref is the commit of flamenet-e2e
whose protocol vectors the unit-tests job checks against. AccountKdfTest,
PQVectorTest and PublishedVectorsTest all read them.
🔴 It exists because a merge in that repository could stop all work in this
one. flamenet-relay learned this the hard way: its jobs cloned main at HEAD,
and the switch got thrown three times in twelve hours (flamenet-relay#56). Once
it was a deadlock with no way out from inside either repository — that repo
expected a change this one had not made, so every pipeline failed, including
the pipeline for the branch that made it. See .e2e-ref.md there for the full
account; the conclusion was that a pin makes that situation impossible rather
than survivable.
⚠️ A pin alone is worse than HEAD, though. The argument for HEAD is real: a
client tested against a pinned old harness is tested against a pinned old spec,
and if the vectors move and nothing says so, this suite quietly stops checking
the protocol anybody is actually running. That is why vectors-head exists and
is allow_failure: true.
Being behind is LOUD and NON-BLOCKING. Being broken is a hard stop. A red
vectors-head means an update is waiting, not that anything is wrong.
Taking an update
One MR, both parts together:
- Put the new e2e commit in
.e2e-ref. - If the vectors themselves changed, read what changed before accepting it — a moved vector is a protocol change, and this app is one of the two ends that has to agree about it.