fix(notifications): true pending count for NavBar badge — not page-capped (#1143)#1145
Merged
Conversation
…ped (#1143) `stores/notifications.js:fetchPendingCount()` read `count` off `GET /api/notifications?status=pending&limit=1`, where `count` is `len(returned page)` — so the polled NavBar badge clamped to 1 every 60s regardless of how many pending notifications existed. - Add `GET /api/notifications/count?status=pending` — returns the true total scoped to the caller's accessible agents (mirrors the per-agent `/api/agents/{name}/notifications/count`). Registered before the `/{notification_id}` catch-all (Invariant #4). - `db.count_pending_notifications` gains an `agent_names` list filter (fleet count over accessible agents); empty list → 0, not "all" (avoids invalid `IN ()`). - Point `fetchPendingCount()` at the new endpoint. Verified live: a fleet with 32 pending now reports 32 (old limit=1 query still returns 1); `/{id}` route unshadowed (404 on unknown id); invalid/unsupported status → 400; unauth → 401. Related to #1143 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Resolve by running |
# Conflicts: # src/backend/routers/notifications.py
vybe
approved these changes
Jun 12, 2026
vybe
left a comment
Contributor
There was a problem hiding this comment.
Validated via /validate-pr: root cause correct (list endpoint count is page-capped), new /count endpoint mirrors list-endpoint access scoping, route ordering (Invariant #4) and parameterized IN clause verified, empty-accessible-set fails closed. CI fully green across all 6 pytest seeds + regression diff. Live verification documented in PR body.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
stores/notifications.js:fetchPendingCount()read thecountfield offGET /api/notifications?status=pending&limit=1, but thatcountislen(returned page)— capped bylimit. The polled NavBar badge therefore clamped back to 1 on every 60s poll, no matter how many pending notifications existed. (WSaddNotificationcould push it higher between polls, then the next poll reset it.)Fix
GET /api/notifications/count?status=pending— returns the true total scoped to the caller's accessible agents, mirroring the per-agent/api/agents/{name}/notifications/count. Registered before the/{notification_id}catch-all (Invariant fix: add missing logging_config.py to backend Dockerfile #4).db.count_pending_notificationsgains anagent_nameslist filter for the fleet count over accessible agents. Empty list →0(not "all"), guarding against invalidIN ()SQL.fetchPendingCount()now hits the new endpoint.Currently only
status=pendingis countable at the DB layer (the only badge case); other statuses 400 explicitly rather than silently miscounting.Verification (live instance)
GET /notifications/count?status=pending?status=pending&limit=1countGET /notifications/{unknown-id}/countdoes not shadow the param routestatus=acknowledged/status=bogusScope
Bug fix — no architecture.md/requirements change (notifications endpoints aren't documented there). Touches 4 files: db method, facade passthrough, router, store.
Closes #1143
🤖 Generated with Claude Code