[dpozimski]

Problem

GET /api/quota/pools/[id]/usage passes the provider plan's per-account dimensions straight to poolUsageWithDimensions, while enforce.ts multiplies every dimension limit by the pool's member-connection count before deciding anything (the summed budget). For a multi-connection pool the snapshot therefore reports limits and fair shares N times smaller than what enforcement actually uses.

I hit this in production today: a 27-connection pool with a usd/daily plan limit of 66.67 (enforced budget 1800.09) had consumed 54.09. The Quota Share page showed 81% utilisation; real utilisation was 3%. The per-key borrowing flags have the same problem: they trip once a key crosses weight% of the per-account limit instead of weight% of the summed budget, so on that pool they fire 27x too early.

Fix

Scale the resolved plan dimensions by accountCount in the usage route before calling the store, using the same computation and legacy fallback as enforce.ts (connectionIds.length, falling back to 1 when the array is missing or empty). Snapshot limit, fairShare, deficit and borrowing then all describe the budget that is enforced. Single-connection and legacy pools are unchanged (N=1), and the { usage: snapshot } wrapper contract is untouched.

Scaling at the route level covers both store drivers, since sqlite and redis both receive their dimensions from this one caller.

Tests

Added tests/unit/quota-pool-usage-summed-budget.test.ts, following the pattern of quota-summed-budget.test.ts (which pins the same multiply on the enforcement side) and quota-pool-usage-shape.test.ts: structural assertions that the route applies the multiply with the right fallback, plus a logic-level check that the scaled limit corrects fairShare and borrowing for the 27-connection case above.

Ran locally:

node --import tsx/esm --test tests/unit/quota-pool-usage-summed-budget.test.ts \
  tests/unit/quota-pool-usage-shape.test.ts \
  tests/unit/quota-summed-budget.test.ts \
  tests/unit/quota-sharing-fixes.test.ts
# 23 pass, 0 fail

npm run lint (scoped to the two changed files) is clean.

[dpozimski]

hi @diegosouzapw , would be great if u can look on it , thanks!

[diegosouzapw]

Correct, production-reproduced bug fix — GET /api/quota/pools/[id]/usage now multiplies each plan dimension limit by accountCount. However, the PR targets the dead release/v3.8.49 and is BLOCKED. Please retarget to main and resolve the merge conflict — then it's good to merge.

[dpozimski]

Retargeted to main and resolved the conflict. The branch was originally cut from the release lineage, so rather than rebase 13 commits I rebuilt it from main and cherry-picked the fix commit, which applied cleanly. The conflict was all release-branch history, not the change itself. Re-verified against main: enforce.ts there still applies the same accountCount multiply, the 4 quota test files pass (23/23), and eslint is clean on both changed files. Should be good to merge now.

[diegosouzapw]

Correct, production-reproduced bug fix — GET /api/quota/pools/[id]/usage now multiplies each plan dimension limit by accountCount. However, the PR targets the dead release/v3.8.50 and is BLOCKED. Please retarget to main and resolve the merge conflict — then it's good to merge.

[dpozimski]

Retargeted to main and force-pushed. Head is now 40c1204b9: one commit, the same two files, merges into main clean. There wasn't a conflict to resolve, main is the base this commit was written on in the first place.

Tests still pass on that tree:

node --import tsx/esm --test tests/unit/quota-pool-usage-summed-budget.test.ts \
  tests/unit/quota-pool-usage-shape.test.ts \
  tests/unit/quota-summed-budget.test.ts \
  tests/unit/quota-sharing-fixes.test.ts
# 23 pass, 0 fail

The old head c899d3f93 was a merge of this same commit into release/v3.8.50, and both changed files were byte-identical across the two, so the rewrite didn't drop anything. It's parked on my fork as backup/quota-pool-usage-summed-budget-merge if you want it back.

One thing I want to raise before you merge, because it might change what you want here. release/v3.8.50 still looks like the branch everything lands on: it's the repo's default branch, the last 30 merged PRs all targeted it (#10520 went in yesterday), and 29 of the 30 currently open PRs target it. main hasn't moved since Aug 13 and is 2282 commits behind. Merging this into main fixes main, but the 27-connection pool I hit is served off the release line, so it keeps reporting 81% utilisation for a pool that's actually at 3%. Happy to open a second PR against release/v3.8.50 (the backup commit is exactly that, and it merges clean), or you can cherry-pick once this lands. Whichever you prefer.