Skip to content

fix(history): calculate utilisation in budget cost units - #14

Merged
alice-viola merged 2 commits into
masterfrom
fix/weighted-history-utilisation
Sep 7, 2026
Merged

fix(history): calculate utilisation in budget cost units#14
alice-viola merged 2 commits into
masterfrom
fix/weighted-history-utilisation

Conversation

@albertovincenzi

Copy link
Copy Markdown
Collaborator

Problem

Historical charts divided admitted item count by ceilings expressed in cost units. A message costing 7 appeared to consume 1 unit, understating utilisation by 7x. Target rollups also cannot attribute aggregate traffic to a whenOp or scopeBy budget, yet the UI drew a precise-looking percentage anyway.

Fix

  • return both admitted items and admitted estimated cost from the flow query;
  • calculate overview utilisation from cost while retaining item counts for volume;
  • ignore operation-selective budgets when choosing a target-level comparable ceiling;
  • reconstruct budget history from cost_estimated rather than admitted;
  • expose whenOp in graph detail so the UI can identify non-attributable histories;
  • show an explicit “not attributable” explanation for scoped/conditional budgets;
  • retain an admitted-count fallback for legacy rollup rows whose cost column is zero.

Review notes for Alice

No enforcement changes here. The live counter remains authoritative. This PR only prevents mixing two currencies and refuses to manufacture a historical percentage when the schema lacks the required operation/scope dimension.

The flow response adds cost but preserves admitted, total_admitted, ceiling, and utilisation for compatibility.

Verification

  • cargo test -p gate-server
  • cargo clippy -p gate-server --all-targets -- -D warnings
  • npm run build in ui/
  • direct Node assertion: 2 admitted items at cost 7 against cap 20 renders 70%, and scoped history returns unknown

albertovincenzi and others added 2 commits September 4, 2026 23:15
`settle_head` is the last resort, and it counted the admission without the
weight: `forwarded`, `admitted` and `commits` went up, `cost` did not. The batch
path in `stage_and_commit` records both.

That was a skew in `avg_cost` until this branch, which is why it survived. This
branch makes `cost_est` the numerator of utilisation, and the roll-up is written
from the same atomic — so a stage that falls back to `settle_head` under
contention reports a utilisation far below the true one, and `/api/flow` reads
"safe" at the moment the counter is at its ceiling. The SQL fallback does not
cover it either: `NULLIF(SUM(cost_est), 0)` only fires when the whole minute is
zero, so a minute mixing both paths under-reports with nothing to catch it.

Same weight, same source, same saturating add as the batch path.

Claude-Session: https://claude.ai/code/session_012K8u7BEJyd6nDNMCQAgH3z
@alice-viola
alice-viola merged commit 45eed29 into master Sep 7, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants