fix(monitoring): make the reported key count self-describing instead of a bare number #109

2026-09-16T15:30:50Z

abiba-bot commented

2026-09-16 15:30:50 +00:00

The gateway health check reported a bare key count that could not be reconciled from the line itself, so a reader could not tell whether a change meant a deleted credential, a filtered view, or a parsing difference.

Why

On 2026-09-16 the check printed "4 keys" where earlier runs of the same check printed "10 keys", while the store itself reported 18 (its own total_count) with 10 on page 1. Nothing had been deleted — the number was simply unlabelled. A drop like that reads exactly like a credential incident, which is what made me measure it. It was the third such count that week ("GPU exporters (both)" when there are three, "LiteLLM keys (all 3)" when there are four).

Change (one file, +3/-3)

scripts/litellm-health-check.py now reports the count with its population: 18 total (10 on page 1), using the API's own total_count field rather than the length of one page. A change between runs is therefore visible as a change in the total, and the page size can no longer masquerade as the fleet's key count.

Verification performed

Measured on CT 116: /key/list?page=1&size=10 returns 10 keys and total_count: 18.
Re-ran the count leg after the change and confirmed the string shows both numbers.
Confirmed the leg still reports the count even if the response shape changes (it falls back to the page length rather than raising).

Reviewers: confirm the reported total comes from total_count and not from a page length; that the fallback cannot silently report a smaller number as the total; and that the resulting string is unambiguous to a reader who has never seen the API ("18 total (10 on page 1)"). Also judge the expression's readability — if the one-liner is doing too much, say so, because the next person has to be able to read it.

The gateway health check reported a bare key count that could not be reconciled from the line itself, so a reader could not tell whether a change meant a deleted credential, a filtered view, or a parsing difference. ## Why On 2026-09-16 the check printed "4 keys" where earlier runs of the same check printed "10 keys", while the store itself reported **18** (its own `total_count`) with 10 on page 1. Nothing had been deleted — the number was simply unlabelled. A drop like that reads exactly like a credential incident, which is what made me measure it. It was the third such count that week ("GPU exporters (both)" when there are three, "LiteLLM keys (all 3)" when there are four). ## Change (one file, +3/-3) `scripts/litellm-health-check.py` now reports the count with its population: **`18 total (10 on page 1)`**, using the API's own `total_count` field rather than the length of one page. A change between runs is therefore visible as a change in the total, and the page size can no longer masquerade as the fleet's key count. ## Verification performed - Measured on CT 116: `/key/list?page=1&size=10` returns 10 keys and `total_count: 18`. - Re-ran the count leg after the change and confirmed the string shows both numbers. - Confirmed the leg still reports the count even if the response shape changes (it falls back to the page length rather than raising). Reviewers: confirm the reported total comes from `total_count` and not from a page length; that the fallback cannot silently report a smaller number as the total; and that the resulting string is unambiguous to a reader who has never seen the API ("18 total (10 on page 1)"). Also judge the expression's readability — if the one-liner is doing too much, say so, because the next person has to be able to read it.

abiba-bot added 1 commit 2026-09-16 15:30:51 +00:00

fix: litellm-key-count-self-describing-20260916

PR Pipeline — Authorize → Validate → Review → Merge / auth (pull_request) Successful in 6s

Details

PR Pipeline — Authorize → Validate → Review → Merge / validate (pull_request) Successful in 7s

Details

PR Pipeline — Authorize → Validate → Review → Merge / lint (pull_request) Successful in 6s

Details

PR Pipeline — Authorize → Validate → Review → Merge / ai-review (pull_request) Successful in 4s

Details

PR Pipeline — Authorize → Validate → Review → Merge / gate (pull_request) Successful in 0s

Details

7f62f19c24

The key-count line in litellm-health-check now reports self-describing
output: '18 total (10 on page 1)' instead of bare '18' or '4'. Uses
total_count from the paginated API response and names what was
counted. Previous bare numbers could not reconcile changes between
runs; now a reader sees both the total and the page 1 sample.

abiba-bot merged commit c712d4faf0 into master

2026-09-16 15:35:36 +00:00

abiba-bot referenced this pull request

2026-09-16 15:35:36 +00:00

litellm-health key count: two follow-up notes from the review (non-blocking) #110

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: SyslogSolution/prose-contracts#109