Split the connections chart into a gauge and a counter - #417
Conversation
The server dashboard plotted numbackends and sessions as two series on one shared axis, which is a category error: numbackends is a gauge bounded by max_connections and usually sits in the tens, whilst sessions is a cumulative counter that only climbs until the statistics are reset and readily reaches the thousands. The counter therefore set the scale, the gauge collapsed into a flat line along the bottom, and the legend invited the reader to compare the two as though both were concurrent figures. The section now renders two charts from the same metrics query. Connections shows backends with a max_connections reference series, which is where the useful signal lives, since a backend count trending towards the limit means exhaustion risk. Sessions Established keeps the counter on its own axis, with the legend naming it as cumulative so nobody mistakes it for a rate. Both titles state that the figures cover the monitored database, because the pg_stat_database probe filters on current_database() and so undercounts the server total. The limit comes from the latest pg_server_info row via the latest-row mode of the metrics query API; that probe only stores a row when the server configuration changes, so a bucketed query would usually come back empty, and the reference series is simply omitted when the limit is unknown. Closes #403
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 12 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
WalkthroughThe PostgreSQL server dashboard now separates backend and cumulative session charts. It retrieves ChangesPostgreSQL dashboard metrics
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant Dashboard as PostgresOverviewSection
participant API as API client
participant Metrics as pg_server_info
participant Charts as Dashboard charts
Dashboard->>API: Request latest pg_server_info row
API->>Metrics: Query max_connections
Metrics-->>API: Return connection limit
API-->>Dashboard: Return validated max_connections
Dashboard->>Charts: Render backend chart with limit and session chart separately
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 121 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
|
@coderabbitai review |
✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@client/src/components/Dashboard/ServerDashboard/__tests__/PostgresOverviewSection.test.tsx`:
- Around line 235-290: Update the response-validation tests around renderSection
and seriesNamesFor to use deferred apiGet promises: resolve a valid
max_connections value first, rerender with a new connectionId, then resolve an
invalid or non-array response and await the lookup state transition before
asserting only Backends is present. Replace the unmount-only assertion in the
aborted-request test with this rerender-and-resolution scenario, verifying the
stale valid response cannot add a reference series for the new connection.
In `@client/src/components/Dashboard/ServerDashboard/PostgresOverviewSection.tsx`:
- Around line 91-124: Update useMaxConnections to store the fetched
max-connections value together with the connectionId that produced it, and
return null whenever the stored ID differs from the current connectionId. Ensure
the effect updates both fields only for the active, non-aborted request, then
add a rerender test covering a connection change while the second lookup remains
pending.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 9a4e49b5-a633-41cc-9075-98153855f745
📒 Files selected for processing (4)
.claude/react-expert/quality-checklist.mdclient/src/components/Dashboard/ServerDashboard/PostgresOverviewSection.tsxclient/src/components/Dashboard/ServerDashboard/__tests__/PostgresOverviewSection.test.tsxdocs/changelog.md
Address review feedback on the connections chart. The hook kept the previously fetched limit in state whilst a new lookup was in flight, so switching connection could briefly draw one server's max_connections line over another server's backend count. The result now carries the connection it came from and is discarded when that no longer matches. The reference-series tests settle deferred lookups by hand rather than asserting against the initial pre-fetch render, so each case observes a genuine transition, and the teardown tests assert that the request's abort signal actually fires on unmount.
|
@coderabbitai review |
|
|
@coderabbitai review |
|
1 participant
Summary
PostgresOverviewSectionplottednumbackendsandsessionsas twoseries on one shared axis, which mixes two different kinds of
quantity.
numbackendsis a gauge, bounded bymax_connectionsandtypically in the tens;
sessionsis a cumulative counter that onlyclimbs until
stats_resetand readily reaches the thousands. Thecounter set the scale, the gauge flattened into a line along the
bottom, and the legend invited the reader to compare "40 backends"
with "85,000 sessions" as though both were concurrent.
The section now renders two charts from the same metrics query, so no
extra time-series request is made:
Connections (Monitored Database) shows backends together with a
Max Connectionsreference series, since a backend count trendingtowards the limit is the signal worth seeing. The reference value
comes from the latest
pg_server_inforow through the latest-rowmode of
/api/v1/metrics/query; that probe only stores a row whenthe server configuration changes, so a bucketed query would usually
come back empty. When the limit is unknown the reference series is
simply omitted.
Sessions Established (Monitored Database) keeps the counter on
its own axis, with the legend naming it
Cumulative Sessionsso itis not mistaken for a rate.
Both titles state the per-database scope, because the
pg_stat_databaseprobe filters oncurrent_database()and soundercounts the server total; it also misses walsenders and autovacuum
workers, which still consume connection slots.
The reference line is drawn as a constant series rather than an
ECharts
markLine, becauseChartdoes not register theMarkLinecomponent and
deepMergeassigns arrays wholesale, so passingseriesthroughechartsOptionswould replace the real data.Deliberately out of scope
The cleanest long-term treatment of the session counter is a
per-second rate, which would show connection churn directly. That
belongs with #400, which covers raw counters that should be rates
across the dashboard, and is left to it rather than expanded into
this PR. The stacked
pg_stat_activitybreakdown of active, idle andidle-in-transaction suggested in #403 is likewise a larger piece of
work needing a new probe series, and is not attempted here. The
change is confined to
PostgresOverviewSection.tsxand its tests, soit does not overlap #404's branch.
Test plan
New
client/src/components/Dashboard/ServerDashboard/__tests__/PostgresOverviewSection.test.tsxwith 18 tests covering the split (asserting that no chart carries
both series), the reference series values, the latest-row query
parameters, the missing/zero/non-array/failed/aborted
max_connectionspaths, the empty and loading panel states, the remaining charts, and
the KPI tiles.
cd client && make coverage: 172 test files, 3506 tests passing.PostgresOverviewSection.tsxreports 100% statements, 100% lines,100% functions and 97.46% branches, comfortably above the 90% floor.
npm run lintis clean for both changed files (0 errors, and the40 warnings in the repository are pre-existing and elsewhere), and
npm run typecheckreports no errors for either file.Visual validation was not possible: neither the dev server nor the
Vite client was running on the dev host, and they are started
manually by the developer, so no browser check was made.
.claude/react-expert/quality-checklist.mdgains a "Dashboard ChartSemantics" section recording the gauge-versus-counter rule and the
markLinecaveat.Closes #403
Summary by CodeRabbit
New Features
max_connectionsreference line to connection charts when available.Bug Fixes
Documentation