fix(alerts): show every notification channel on the summary line - #2991
fix(alerts): show every notification channel on the summary line#2991jordan-simonovski wants to merge 2 commits into
Conversation
AlertPropertiesSummary read `alert.channel` — the legacy single-value mirror of channels[0] — so an alert configured with several notification targets rendered as though it had one, with nothing to say the others existed. Dispatch was always correct, so this is a reporting gap rather than a delivery one. It points the wrong way, though: someone checking which targets an alert notifies is shown one, and would reasonably conclude a channel never saved. A single channel still names its webhook, so the common case is unchanged. Several channels render an icon each plus a count, which stays bounded at the ten channels the API allows. Both surfaces that share the component — the alerts page rows and the alert detail page — are fixed together.
🦋 Changeset detectedLatest commit: ffec01c The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🔵 Tier 2 — Low RiskSmall, isolated change with no API route or data model modifications. Why this tier:
Review process: AI review + quick human skim (target: 5–15 min). Reviewer validates AI assessment and checks for domain-specific concerns. Stats
|
Greptile SummaryThe PR updates the shared alert-properties summary to represent the canonical notification-channel list while retaining the legacy singular-channel fallback.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains.
|
| Filename | Overview |
|---|---|
| packages/app/src/components/alerts/AlertPropertiesSummary.tsx | Uses the canonical channels list for summary rendering, falls back to the legacy channel object, and preserves the single-channel webhook label. |
| packages/app/src/components/alerts/tests/AlertDetailProperties.test.tsx | Adds focused coverage for multi-channel counts and preservation of the single-channel webhook name. |
| .changeset/alert-properties-all-channels.md | Documents the user-visible alert-summary correction as an application patch. |
Reviews (2): Last reviewed commit: "Merge branch 'main' into claude/alert-pr..." | Re-trigger Greptile
Deep ReviewScope: 1 component + 1 test + 1 changeset ( The change is small, correct on the happy path, and backward-compatible: 🟡 P2 — recommended
🔵 P3 nitpicks (1)
Reviewers (7): correctness, testing, maintainability, project-standards, kieran-typescript, agent-native, learnings-researcher. Testing gaps: The explicit empty-array case ( Note: prior PR comments were bot-only (changeset-bot, vercel), so the previous-comments reviewer was not run — there was no human feedback to verify. |
E2E Test Results❌ 1 test failed • 306 passed • 1 skipped • 1057s
Tests ran across 4 shards in parallel. |
|
Superseded by #3001. |
Why
AlertPropertiesSummaryreadsalert.channel— the legacy single-value mirror ofchannels[0]— so an alert configured with several notification targets renders as though it has one, with nothing to indicate the others exist. Multi-channel alerts have been supported since #2845–#2848; this surface never caught up.Dispatch is correct, so this is a reporting gap rather than a delivery one. It does point the wrong way, though: someone checking which targets an alert notifies is shown one, and would reasonably conclude a channel hadn't saved.
Both surfaces that share the component are affected — the alerts page rows and the alert detail page.
What changed
Render
channelswhen present, falling back to[alert.channel]otherwise, so rows written before multi-channel (and an alert with a null-typed channel) render exactly as they did.A single channel still names its webhook — a count there would be a regression for the overwhelmingly common case. Several channels render an icon each plus a count, bounded by the ten the API allows.
Testing
Two tests on
AlertDetailProperties: a two-channel alert reports2 channels, and a single-channel alert still names its webhook. Verified the first fails onmain; the second passes either way by design, as parity cover.make ci-lint(0 errors) andmake ci-unit(3115 app tests) in an upstream checkout.Note on scope
I kept this to a count rather than listing every channel's name. Resolving N webhook names means the caller fetching and threading N lookups, and an alerts-page row has no room for ten names. Happy to go further if you'd rather the detail page enumerate them.
Found while merging this stack into the ClickHouse EE fork, where the same components had drifted out of step with the multi-channel model.