Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:seuhswgn3l was degraded 60 minutes today: trevato/forge: "muting a repository's asks > the home offers the chip, and a muted repository's pull leaves every list"… #6190
Check · Review · Land · Live done — Landed and live in production.
This pull stops two test files from reading the check machine's free disk. I couldn't reproduce the original `asks-mute` failure, so the disk cause is likely but not proven.
shipped production is serving it deploy f18c0e5
This pull stops two test files from reading the check machine's free disk. I couldn't reproduce the original asks-mute failure, so the disk cause is likely but not proven.
Cause. The mute test compares askCountFor(ctx, alice) with forgeNeedsFor(ctx, alice).length. An admin's count includes the forge's own needs, and one of those is "Disk is nearly full". The test read free space from the real volume under its temp directory. At about 10% free, the need can appear between the two reads, and the two numbers then disagree.
Evidence. In this sandbox the disk was at 9% free. That made test/asks-expiry.test.ts fail on its own with "2 things need you" instead of "1" and "1 thing needs you" instead of "All fine". test/asks-mute.test.ts passed here, including 60 parallel runs.
What changed. test/asks-mute.test.ts and test/asks-expiry.test.ts now pass createApp a fixed disk reading, which AppConfig already offers for tests. I put the fix in asks-expiry too because it has the same cause.
What I didn't do. I couldn't see the failing check's log, so I haven't confirmed that disk was what failed on those pulls. Other test files that make an admin's ask count depend on the machine's disk will have the same problem, and I didn't audit them. I didn't touch forgeVitals.
Checks. Both files pass (15 tests). I couldn't run tsc here because the bun types aren't installed. To try it, run bun test test/asks-mute.test.ts test/asks-expiry.test.ts.
Two test files now pass createApp a fixed disk reading (AppConfig.disk exists, src/app.ts:42), so the admin ask count no longer depends on the check machine free space. Small, single-purpose, no production code touched, matches the direction (tests that never flake). The cause for asks-mute is plausible but unproven; asks-expiry is demonstrated. Two things next: (1) audit other test files that count an admin ask/needs and read the real disk, or make the test default app config use a fixed reading; (2) the duplicated inline disk lambda in both files could be a shared test helper.
The new message on #6189 is only the automatic triage note filing the issue under P0 Trust. It asks for nothing new, so I made no further changes. The branch matches origin, and the fix from the earlier push is the whole change.
What changed. test/asks-mute.test.ts and test/asks-expiry.test.ts now give createApp a fixed disk reading. An admin's ask count includes the forge's own needs, and one of those is "Disk is nearly full". Both tests used to read free space from the real volume under their temp directory.
Why the mute test flaked. The mute test compares askCountFor with forgeNeedsFor(...).length in two separate reads. When the machine sits near the 10% free threshold, the disk need can appear between the two reads and the numbers disagree. In this sandbox the disk was at 9% free, and asks-expiry failed on its own with an extra "thing needs you".
What I couldn't confirm. I never reproduced the asks-mute failure, even in 60 parallel runs, and I couldn't see the failing check's log. The disk cause is the best match I found, not a proven one.
What I left out.
- Other tests that count an admin's asks may have the same dependence on the machine's disk. I didn't audit them.
- I didn't change
forgeVitals.
Checks. Both files pass (15 tests). tsc doesn't run in this sandbox because the bun types aren't installed, so the forge's check will be its first run.
To try it. Run bun test test/asks-mute.test.ts test/asks-expiry.test.ts.
This pull stops two test files from reading the check machine's free disk. I couldn't reproduce the original
asks-mutefailure, so the disk cause is likely but not proven.Cause. The mute test compares
askCountFor(ctx, alice)withforgeNeedsFor(ctx, alice).length. An admin's count includes the forge's own needs, and one of those is "Disk is nearly full". The test read free space from the real volume under its temp directory. At about 10% free, the need can appear between the two reads, and the two numbers then disagree.Evidence. In this sandbox the disk was at 9% free. That made
test/asks-expiry.test.tsfail on its own with "2 things need you" instead of "1" and "1 thing needs you" instead of "All fine".test/asks-mute.test.tspassed here, including 60 parallel runs.What changed.
test/asks-mute.test.tsandtest/asks-expiry.test.tsnow passcreateAppa fixeddiskreading, whichAppConfigalready offers for tests. I put the fix inasks-expirytoo because it has the same cause.What I didn't do. I couldn't see the failing check's log, so I haven't confirmed that disk was what failed on those pulls. Other test files that make an admin's ask count depend on the machine's disk will have the same problem, and I didn't audit them. I didn't touch
forgeVitals.Checks. Both files pass (15 tests). I couldn't run
tschere because thebuntypes aren't installed. To try it, runbun test test/asks-mute.test.ts test/asks-expiry.test.ts.Closes #6189