Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:2m4jgo7fd2 is past its budget: trevato/forge: "the access log's keeping > files older than 14 days go, and the directory stays under its cap" failed o… #6962
Check · Review · Land · Live done — Landed and live in production.
The access-log keeping test no longer depends on how fast the check machine's disk is. I couldn't reproduce the failure here, so I'm inferring the cause: the test wrote two files of about 64 MB each to reach the 128 MB cap, and a loaded disk could push that past the test timeout.
shipped production is serving it deploy 12e5a4a
The access-log keeping test no longer depends on how fast the check machine's disk is. I couldn't reproduce the failure here, so I'm inferring the cause: the test wrote two files of about 64 MB each to reach the 128 MB cap, and a loaded disk could push that past the test timeout.
- Change:
prune()insrc/http/access_log.tsnow takes an optionalcapargument that defaults toTOTAL_BYTES, so production behaviour is the same. The test passes a 1 KiB cap and writes tiny files. - Unchanged: the test still checks the same two things — files older than 14 days go, and the oldest file goes first when over the cap while today's file stays.
- Checks run:
bun test test/access-log.test.tspasses (10 tests) andbun x tsc --noEmitis clean. The test needed no other change, apart from dropping its now-unusedTOTAL_BYTESimport. I did not run the full check; the forge runs that on push. - Left out: I did not add a separate test for the default cap, because the default is the constant
prune()already used.
Clean, small and single-purpose. It fits the pipeline direction: it removes a flaky, disk-bound test (two ~64 MB writes) from the gate without changing production behaviour.
prune()gets an optionalcapthat defaults toTOTAL_BYTES. Its only production caller (recordAccess, access_log.ts:232) still passes two arguments, so the 128 MB cap is unchanged. No user input reachescap.- The test still pins both behaviours: files past 14 days go, and over the cap the oldest goes first while today's file stays. With a 1 KiB cap it now writes about 1 KB in place of 128 MB.
- Security: no new input, output, write path or dependency.
bun test test/access-log.test.ts: 10 pass, 0 fail. The preview answers/with 200. There is no UI or terminal surface to check.
The access-log keeping test no longer depends on how fast the check machine's disk is. I couldn't reproduce the failure here, so I'm inferring the cause: the test wrote two files of about 64 MB each to reach the 128 MB cap, and a loaded disk could push that past the test timeout.
prune()insrc/http/access_log.tsnow takes an optionalcapargument that defaults toTOTAL_BYTES, so production behaviour is the same. The test passes a 1 KiB cap and writes tiny files.bun test test/access-log.test.tspasses (10 tests) andbun x tsc --noEmitis clean. The test needed no other change, apart from dropping its now-unusedTOTAL_BYTESimport. I did not run the full check; the forge runs that on push.prune()already used.Closes #6952