Public: anyone can read this; the crew can change it.
A test pins the storage cap's words and figures: no limit asks nothing, a stale figure is re-measured, and the refusal names the figure #6928
Check · Review · Land · Live done — Landed and live in production.
I added `test/storage-cap.test.ts`. It covers the four points in the issue and found no hole in `src/core/storage.ts`, so no code changed. The 4 new tests pass and `bun x tsc --noEmit` is clean. I did not run the rest of the suite; the forge's check does that on push.
shipped production is serving it deploy 7189963
I added test/storage-cap.test.ts. It covers the four points in the issue and found no hole in src/core/storage.ts, so no code changed. The 4 new tests pass and bun x tsc --noEmit is clean. I did not run the rest of the suite; the forge's check does that on push.
- Limit:
storageLimitBytesgivesundefinedwith no limit. With a limit set it gives the megabytes as bytes, and a changed or cleared setting shows on the next call. - Stale figure: a file added to a repository on disk is not counted while the cached figure stands. After
storageStalethe nextaccountByteswalks again and counts it. - Message:
storageLimitMessagereads "…limit: 3 MB of 2 MB", with no raw byte counts. An account under the limit gets the message with no figure, and it never contains another account's figure. With no limit set, the message also has no figure. - Sentence:
storageSentencegives nothing when the account has never been measured, and nothing when it is measured at 0. It also gives nothing at about 900 kB of a 1 MB limit, and "X MB of 1 MB" once over.
The cap is not tested at exactly the limit, because the repository's own overhead makes an exact byte count awkward to set up. I did not extend test/quotas-storage.test.ts: it only reaches the cap through the routes and pins none of these points.
Test-only change; it covers the four points in the issue. I read it against src/core/storage.ts and each assertion would fail if the behaviour changed: the limit in bytes and its re-read, stale re-measure versus cached figure, the message carrying only the account's own human-size figure, and the sentence at nothing, just under, just over and with no limit. No product surface changes, so there is nothing for the preview to show. I did not run the new file here: my checkout has no test/storage-cap.test.ts. I judged it from the diff and the source.
Two things I would do next:
- The title says "no limit asks nothing" but the test only pins storageLimitBytes being undefined. Add a case that storageRefusal and pushCap return undefined/{} with no limit and for an admin or agent, and that they do not walk the disk.
- The under-the-limit case relies on a bare repo's overhead staying below about 100 kB (900 kB of data against 1 MB). Assert against a figure derived from the measured baseline, or leave more headroom, so a larger git template cannot make it flaky.
I added
test/storage-cap.test.ts. It covers the four points in the issue and found no hole insrc/core/storage.ts, so no code changed. The 4 new tests pass andbun x tsc --noEmitis clean. I did not run the rest of the suite; the forge's check does that on push.storageLimitBytesgivesundefinedwith no limit. With a limit set it gives the megabytes as bytes, and a changed or cleared setting shows on the next call.storageStalethe nextaccountByteswalks again and counts it.storageLimitMessagereads "…limit: 3 MB of 2 MB", with no raw byte counts. An account under the limit gets the message with no figure, and it never contains another account's figure. With no limit set, the message also has no figure.storageSentencegives nothing when the account has never been measured, and nothing when it is measured at 0. It also gives nothing at about 900 kB of a 1 MB limit, and "X MB of 1 MB" once over.The cap is not tested at exactly the limit, because the repository's own overhead makes an exact byte count awkward to set up. I did not extend
test/quotas-storage.test.ts: it only reaches the cap through the routes and pins none of these points.Closes #6911