feat(dashboards): release markers on tile charts - #2894
Conversation
🦋 Changeset detectedLatest commit: 468ed6e 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.
|
Greptile SummaryDashboard time-series tiles can now display URL-controlled release markers derived from version values in their log or trace source.
Confidence Score: 5/5The PR appears safe to merge because no blocking failure remains. No blocking failure remains.
|
| Filename | Overview |
|---|---|
| packages/app/src/hooks/useReleaseAnnotations.tsx | Builds source-scoped release queries and converts first-seen version rows into annotations. |
| packages/app/src/components/charts/chartAnnotations.tsx | Adds annotation merging, series resolution, timestamp validation, and dense-label collapsing. |
| packages/app/src/HDXMultiSeriesTimeChart.tsx | Resolves annotation colors against chart series and supplies plot geometry for label layout. |
| packages/app/src/DBDashboardPage.tsx | Adds the URL-backed release-marker toggle and supplies merged annotations to time charts. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart LR
Toggle[releaseMarkers URL toggle] --> Tile[Dashboard tile]
Tile --> Hook[useReleaseAnnotations]
Hook --> Query[Source-scoped release query]
Query --> Convert[Convert rows to annotations]
Convert --> Merge[Merge with alert annotations]
Merge --> Resolve[Resolve visible series and colors]
Resolve --> Chart[Render time-chart markers]
Reviews (2): Last reviewed commit: "feat(dashboards): release markers on til..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| const releaseAnnotations = useReleaseAnnotations( | ||
| isFullscreen ? fullscreenDateRange : dateRange, | ||
| showReleaseAnnotations, | ||
| { | ||
| source, | ||
| where: isBuilderSavedChartConfig(chart.config) | ||
| ? chart.config.where | ||
| : undefined, | ||
| whereLanguage: isBuilderSavedChartConfig(chart.config) | ||
| ? chart.config.whereLanguage | ||
| : undefined, | ||
| filters, | ||
| }, | ||
| ); |
There was a problem hiding this comment.
When release markers are enabled, every log- or trace-backed tile runs the release aggregation even though only DBTimeChart consumes the annotations, adding discarded ClickHouse queries for table, number, pie, and other non-time-series tiles.
Knowledge Base Used: App Components and Charts
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Deep Review✅ No critical issues found. No P0/P1 defects. The change is well-tested (strong unit coverage on the pure helpers plus a full-stack e2e that asserts markers actually render, are attribution-scoped, and round-trip through the URL) and reuses the existing alert-annotation overlay cleanly. The highest-risk area — parsing ClickHouse timestamp strings for marker placement — was independently verified: the ClickHouse client sets 🟡 P2 -- recommended
Agent-native follow-up
🔵 P3 nitpicks (7)
Reviewers (8): security, testing, maintainability, kieran-typescript, performance, project-standards, agent-native, learnings-researcher. Testing gaps:
|
Correlating a latency or error spike with a release meant leaving the product. Dashboard tiles can now overlay the moment each version of a service first appeared, derived from the version expression on the tile's source, so no CI integration is needed. Markers reuse the annotation overlay built for alert firing/recovery lines, which was written source-agnostic for exactly this. They are off by default, toggled from the dashboard overflow menu, with the state in the URL as `releaseMarkers` so a shared link keeps it. Called release markers rather than deployment markers on purpose. What is detected is a new version value appearing in telemetry, which is not the same as a deployment: a deploy that doesn't change the version string produces no marker at all, and a service idle past the lookback draws one when it scales back up. The narrower name keeps the failure mode legible. Three rules keep them trustworthy rather than noisy. A marker only helps if the reader can attribute it, so what a tile shows depends on what it charts: - Filtered to one service: that service's releases. - Grouped by service: every charted service's releases, each tinted to match its own line. - An aggregate line over many services: none, since a marker naming a service with no visible line invites false attribution. The query runs against the tile's own source with the tile's own filters, which is what makes scoping possible. The version already running when the window opens is recognised and dropped rather than drawn as a release that never happened. Dense clusters collapse to "N releases", sized from the estimated label width; a cluster spanning several services goes neutral rather than wearing one of their colours and claiming the others' releases as its own.
4e044ef to
468ed6e
Compare
🟡 Tier 3 — StandardIntroduces new logic, modifies core functionality, or touches areas with non-trivial risk. Why this tier:
Review process: Full human review — logic, architecture, edge cases. Stats
|
Deep Review✅ No critical issues found. The feature is off by default, gated behind an explicit toggle, and the ClickHouse query it builds reuses the codebase's established trusted-source-config interpolation model (verified against 🟡 P2 — recommended
🔵 P3 nitpicks (3)
Reviewers (11 dispatched): correctness, security, adversarial, testing, maintainability, kieran-typescript, julik-frontend-races, performance, project-standards, agent-native, learnings-researcher. Testing gaps: New logic carries strong unit coverage ( |
E2E Test Results✅ All tests passed • 282 passed • 1 skipped • 1132s
Tests ran across 4 shards in parallel. |
1 participant
Summary
Correlating a latency or error spike with a release meant leaving HyperDX. Dashboard tiles can now overlay the moment each version of a service first appeared, derived from the version expression on the tile's source, so no CI integration is required. Markers reuse the annotation overlay built for alert firing/recovery lines, which was written source-agnostic for exactly this. They are off by default and toggled from the dashboard overflow menu, with the state carried in the URL as
releaseMarkersso a shared link keeps it.They are called release markers rather than deployment markers on purpose. What we detect is a new version value appearing in telemetry, which is not the same as a deployment: a deploy that doesn't change the version string produces no marker at all, and a service idle past the lookback draws one when it scales back up. The narrower name keeps the failure mode legible instead of making the feature look broken.
Three rules keep the markers trustworthy rather than noisy. A marker only helps correlation if the reader can attribute it to something visible, so what a tile shows depends on what it charts:
The query runs against the tile's own source with the tile's own filters, which is what makes scoping possible. The version already running when the window opens is recognised and dropped rather than drawn as a release that never happened. Dense clusters collapse to "N releases", sized from the estimated label width; a cluster spanning several services goes neutral rather than wearing one of their colours and claiming the others' releases as its own.
Markers are available on log and trace sources. Metric sources resolve their table per metric type, so there is no single table to re-aggregate and no way to make a tile's filters meaningful against it; following the source correlation fields to a companion log source is the natural follow-up.
Stack: based on #2893 (the source field this reads). Review that one first. A follow-up PR adds a hover tooltip naming the service behind each marker.
How to test on Vercel preview
Preview routes: /dashboards
Steps:
data-testid="dashboard-menu-button").data-testid="toggle-release-annotations-menu-item").releaseMarkers=trueand the menu item now reads "Hide release markers".releaseMarkersis removed from the URL.Note: whether marker lines render depends on the preview's demo data carrying a version attribute. The steps above assert the toggle and URL state, which hold regardless.
References