[HackTuah]

Two tests were red on one machine and green on the other. The causes turned out to be unrelated, and neither was the product misbehaving.

Skills.RegistryTest AC3 — fixed

On CI there is no inotifywait, so the registry takes the fs_poll backend: a poll every second over mtimes at one-second resolution, whose worst case is about two seconds. AC3's bound is two seconds. No margin at all, and a loaded shared runner closes it. Measured with the backend forced:

fs_poll interval	observed latency	margin against 2000 ms
1000 ms (shipped)	1222, 1223 ms	777 ms
100 ms (suite)	339, 312, 338 ms	~1660 ms

The interval is now configurable and the suite sets 100 ms. The shipped default is unchanged: a desktop does not need a tenth-of-a-second poll, and the criterion is the same either way.

The suite also pins the backend. Which one the registry picks otherwise depends on the machine, so the test measured a different mechanism in each place. And on a box at its inotify instance ceiling the native backend obtains no watch and fails silently:

$ cat /proc/sys/fs/inotify/max_user_instances   ->  128
$ find /proc/*/fd -lname anon_inode:inotify | wc -l   ->  119

That is this machine, and it is why AC3 was red here. Not leaked by the suite: no stray inotifywait processes exist. The old assertion could only report it as

AC3: the edit was in the registry after  ms

because the poll window and the criterion were the same 2000 ms budget, so an exhausted loop and a late arrival were indistinguishable. They are separate now: the loop waits 15 s so a failure says which happened, and the criterion is asserted against the latency actually measured.

Verified where it was failing: three runs at 338, 338 and 312 ms, then a full gate.

mix gate
prod_check: PASS
3814 mods/funs, found no issues.
No vulnerabilities found.
trinity.names: OK over 674 tracked files
AC3: the edit was in the registry after 338 ms
Result: 951 passed (20 properties, 931 tests), 18 excluded
trinity.coverage: 042 80.31% vs 005 80.31%: OK
GATE_EXIT=0

Gateways.IdentitiesTest — diagnosed, not fixed

config/test.exs sets default_transaction_mode: :immediate on both test repos, which reads as though slice 005 had closed R26 for the suite. It has not.

# deps/ecto_sql/lib/ecto/adapters/sql/sandbox.ex:659
case conn_mod.handle_begin([mode: :transaction] ++ opts, conn_state) do

# deps/exqlite/lib/exqlite/connection.ex:298
mode = Keyword.get(options, :mode, state.default_transaction_mode)

The sandbox prepends an explicit :mode, so it wins over the configuration, and :transaction maps to a plain BEGIN TRANSACTION, which is DEFERRED. Every sandboxed test is a DEFERRED transaction. One that reads before it writes is on exactly R26's unguarded upgrade path, where SQLite returns SQLITE_BUSY without consulting the busy handler and no busy_timeout can help. Identities.admit/3 reads and then inserts, with no transaction of its own, and its first statement in the test is that call.

Recorded rather than asserted-and-forgotten: the comment in config/test.exs no longer implies the suite is covered, and test/trinity/repo/sandbox_transaction_mode_test.exs pins both dependency lines so the paragraph fails rather than rots if an upgrade moves them.

The test itself is unchanged. The mechanism needs a second concurrent writer, and I have not identified which process that is: the file is already async: false, DataCase puts it in shared mode so application processes use the owner's connection, and the failure does not reproduce here. I am not shipping a mitigation I cannot demonstrate.

If you want it closed, the cheapest honest option is to make that test's transaction a writer before its first read, since a fresh write consults the busy handler where an upgrade does not. Say so and I will verify the premise against the existing two-connection R26 harness first, rather than assuming it.

A third one, reported not touched

Trinity.SandboxTest "AC3 ... os.time and os.clock still work" failed once during this work:

right: {:error, {:timeout, 1000}}

A 1 s budget for a trivial Lua call. Same family, passed on the next run, outside what you asked for.

No new slice id, no ROADMAP row. Not merged.