By: Tom Sydney Kerckhove <syd@cs-syd.eu>
Defensively read coverage and manifest files strictly
The coverage phase on large projects (~1500 tests, contended resources,
high coverage-job concurrency) intermittently dies with @<<loop>>@
('BlockedIndefinitelyOnMVar' or 'NonTermination', both surface as
@<<loop>>@) between the last 'coverage (N/N): done' line and the
start of the mutation phase. The root cause has not been pinpointed.
As a defensive measure, switch the four runtime read functions from
'LB.readFile' + 'Aeson.decode' to 'B.readFile' + 'Aeson.decodeStrict'
so the file handle is closed and the bytestring fully realised before
each read returns. This removes any chance that lazy I/O leaves a
'Handle' alive across the surrounding 'withSystemTempDir' teardown.
NB: I could not reproduce the original @<<loop>>@ in a unit test. The
new PhaseBoundarySpec exercises the read-then-tear-down and
read-merge-write patterns at modest scale as a smoke test, but it
passes with or without the strict-reads change, so it is documented as
a smoke test only and not as a regression for the actual loop.