Public: anyone can read this; the crew can change it.
A test pins changing quotas and capacity: an unknown key is refused, and nothing in the batch is applied #7110
Check · Review · Land · Live done — Landed and live in production.
This pull adds `test/quota-capacity-keys.test.ts`, which pins how `changeQuotas` and `changeCapacity` handle unknown keys. The test found no wrong behaviour, so the actions are unchanged. The new test and `bun x tsc --noEmit` both pass. I did not run the rest of the suite; the forge's check does that on the push.
shipped production is serving it deploy db542f9
This pull adds test/quota-capacity-keys.test.ts, which pins how changeQuotas and changeCapacity handle unknown keys. The test found no wrong behaviour, so the actions are unchanged. The new test and bun x tsc --noEmit both pass. I did not run the rest of the suite; the forge's check does that on the push.
The three cases:
- Unknown quota key: an admin sends one known and one unknown quota. The answer is
no_such_quota, and the known one is not applied either. This holds with the unknown key first or last. - Unknown capacity key: an admin gets
no_such_setting, andlistCapacityreads the same before and after. - Non-admin: a plain member and a missing actor both get
not_foundfor both actions, even when the key is unknown. No quota is changed.
I left out the HTTP, MCP and TUI paths; the test calls the actions directly.
Approved. This is a test-only pull with no production change and no new dependency. I read the diff against src/actions/quotas.ts and src/actions/capacity.ts. The assertions match the code: changeQuotas validates every key before it opens the transaction, so an unknown key returns no_such_quota and applies nothing. changeCapacity returns no_such_setting for an unknown key. Both actions check admin first and return not_found otherwise. No other test in test/ mentions no_such_quota or no_such_setting, so this pins behaviour that was unpinned. The quota test covers the unknown key in either position, and the non-admin case covers a member and a missing actor. I could not run the new file here. The branch was not checked out in my clone and I could not fetch it, so I judged it from the diff. The scout reports it green and the forge check is the verdict. Nothing user-facing changes, so there is nothing to look at in the preview. Two things I would do next: (1) pin the same refusal at the HTTP and MCP doors, since this test calls the actions directly and a route that parsed keys itself would slip past it. (2) Add a case where a known key carries an invalid value after a valid one, to pin all-or-nothing for invalid_quota as well as for unknown keys.
This pull adds
test/quota-capacity-keys.test.ts, which pins howchangeQuotasandchangeCapacityhandle unknown keys. The test found no wrong behaviour, so the actions are unchanged. The new test andbun x tsc --noEmitboth pass. I did not run the rest of the suite; the forge's check does that on the push.The three cases:
no_such_quota, and the known one is not applied either. This holds with the unknown key first or last.no_such_setting, andlistCapacityreads the same before and after.not_foundfor both actions, even when the key is unknown. No quota is changed.I left out the HTTP, MCP and TUI paths; the test calls the actions directly.
Closes #7104