Four input/output bounds in the in-process admin clients are implemented correctly but have no test pinning them. None of these is a live defect — each mechanism is present in the source, and in two cases the same bound is already asserted on a neighbouring path. They are recorded here so the next reader does not mistake the silence for absence, and so the assertions can be added cheaply.
Found during the review that followed the removal of the HTTP commerce service, whose contract suite had been the only place some of these were exercised.
1. MAX_STOCK_MOVEMENT_QTY has no upper-bound test.
packages/plugin/src/admin/in-process-admin-products-client.ts clamps a stock movement at 1,000,000,000. Nothing asserts that a quantity above the ceiling is refused.
2. MAX_LOW_STOCK_THRESHOLD is untested on the report-read path.
The bound is asserted on the settings-WRITE path in the shared client contract, but the report-read path in packages/plugin/src/admin/in-process-reporting-settings-client.ts applies the same ceiling with no equivalent case.
3. Coupon cursor fail-closed behaviour is implemented but unasserted.
packages/plugin/src/admin/in-process-admin-rules-client.ts refuses a cursor it did not issue — an undecodable token, an out-of-range position, or a filter that no longer revalidates — with a typed input error rather than silently restarting the page. No test drives a forged or stale cursor through it.
4. No guard that a store SKU-uniqueness violation is translated, not echoed.
A unique-constraint violation raised by the store should surface as the domain's typed SKU-conflict refusal, never as a raw driver error reaching the caller. The mapping exists; nothing pins it against a store that actually raises the violation.
Suggested work
Add one case per item, alongside the existing assertions for the neighbouring paths where those exist (items 2 and 3 in particular have an obvious home). Each is a few lines; none requires new fixtures.
Four input/output bounds in the in-process admin clients are implemented correctly but have no test pinning them. None of these is a live defect — each mechanism is present in the source, and in two cases the same bound is already asserted on a neighbouring path. They are recorded here so the next reader does not mistake the silence for absence, and so the assertions can be added cheaply.
Found during the review that followed the removal of the HTTP commerce service, whose contract suite had been the only place some of these were exercised.
1.
MAX_STOCK_MOVEMENT_QTYhas no upper-bound test.packages/plugin/src/admin/in-process-admin-products-client.tsclamps a stock movement at 1,000,000,000. Nothing asserts that a quantity above the ceiling is refused.2.
MAX_LOW_STOCK_THRESHOLDis untested on the report-read path.The bound is asserted on the settings-WRITE path in the shared client contract, but the report-read path in
packages/plugin/src/admin/in-process-reporting-settings-client.tsapplies the same ceiling with no equivalent case.3. Coupon cursor fail-closed behaviour is implemented but unasserted.
packages/plugin/src/admin/in-process-admin-rules-client.tsrefuses a cursor it did not issue — an undecodable token, an out-of-range position, or a filter that no longer revalidates — with a typed input error rather than silently restarting the page. No test drives a forged or stale cursor through it.4. No guard that a store SKU-uniqueness violation is translated, not echoed.
A unique-constraint violation raised by the store should surface as the domain's typed SKU-conflict refusal, never as a raw driver error reaching the caller. The mapping exists; nothing pins it against a store that actually raises the violation.
Suggested work
Add one case per item, alongside the existing assertions for the neighbouring paths where those exist (items 2 and 3 in particular have an obvious home). Each is a few lines; none requires new fixtures.