Skip to content

fix: filter deleted providers out of /api/provider-metrics topology (#10714) - #10742

Merged
diegosouzapw merged 1 commit into
release/v3.8.50from
fix/10714-provider-metrics-ghost-deleted
Aug 19, 2026
Merged

diegosouzapw merged 1 commit into
release/v3.8.50from
fix/10714-provider-metrics-ghost-deleted

Conversation

@diegosouzapw

Copy link
Copy Markdown
Collaborator

Closes #10714

⚠️ base-red inherited: #9985

Root cause

getProviderMetrics() (src/lib/db/callLogStats.ts) aggregates /api/provider-metrics topology data directly from call_logs grouped by provider, with no filter against currently-live provider_connections. Deleting a provider connection (src/lib/db/providers/deletion.ts) never touches call_logs, so a deleted provider's historical rows keep feeding the Home "Provider Topology" widget forever — including a permanent stale "error" node if its last logged status was non-2xx.

Fix

Add AND EXISTS (SELECT 1 FROM provider_connections pc WHERE pc.provider = c.provider) to the getProviderMetrics() query, so only providers with a live connection row surface in topology/metrics. Read-only aggregation query change; sole caller is /api/provider-metrics (the similarly-named MCP handleGetProviderMetrics is an unrelated function hitting different endpoints).

Regression test (TDD, Hard Rule #18)

tests/unit/provider-metrics-deleted-provider.test.ts — seeds a live openai connection + call log, and a g4f-pollinations call log with no matching provider_connections row (simulating a deleted provider). Asserts the deleted provider never appears in topology.providers, metrics, or topology.errorProvider, while the live provider still does.

  • RED (pre-fix): AssertionError: deleted provider must not appear in topology.providers — true !== false
  • GREEN (post-fix): tests 1, pass 1, fail 0

Also updated fixtures in the two existing suites that exercise this query (tests/unit/provider-metrics-route.test.ts, tests/unit/db-call-log-stats-3500.test.ts) to seed provider_connections rows for the providers they assert on — required setup under the new filter, not a weakened assertion.

node --import tsx/esm --test tests/unit/provider-metrics-route.test.ts tests/unit/db-call-log-stats-3500.test.ts tests/unit/provider-metrics-deleted-provider.test.ts
→ tests 10, pass 10, fail 0

Gates run (all clean on touched files)

  • node scripts/check/check-file-size.mjs — OK
  • node scripts/check/check-complexity.mjs — OK (2546 violations vs baseline 2774)
  • node scripts/check/check-cognitive-complexity.mjs — OK (1144 violations vs baseline 1223)
  • node scripts/check/check-changelog-integrity.mjs — OK
  • npx eslint --suppressions-location config/quality/eslint-suppressions.json <touched files> — clean
  • npm run typecheck:core — exit 0

@diegosouzapw
diegosouzapw merged commit b755dd5 into release/v3.8.50 Aug 19, 2026
11 checks passed
@diegosouzapw
diegosouzapw deleted the fix/10714-provider-metrics-ghost-deleted branch August 19, 2026 14:08
muhamadgalihsaputra pushed a commit to niyatna/NiyatnaRoute that referenced this pull request Sep 27, 2026
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.

Removing a provider leaves it stuck as "error" on the Home provider topology forever

2 participants