Skip to content

Diagnostics: fix the empty daily-cost chart - #413

Draft
alex-clickhouse wants to merge 1 commit into
mainfrom
alex-clickhouse/diagnostics-daily-cost-chart
Draft

Diagnostics: fix the empty daily-cost chart#413
alex-clickhouse wants to merge 1 commit into
mainfrom
alex-clickhouse/diagnostics-daily-cost-chart

Conversation

@alex-clickhouse

Copy link
Copy Markdown
Collaborator

The Diagnostics page renders "Daily cost" as a row of bare date labels with no bars. Flagged as known-but-unexplained in #411; this is the explanation and the fix.

Root cause

Frontend only. The backend is healthy — /api/diagnostics returns 8 daily rows with real cost_usd, and get_usage_by_period already emits exactly the date / cost_usd shape the chart reads.

Each bar carries style={{ height: `${heightPct}%` }}. Its parent column was a flex item in an items-end row, so the column's cross size is content-based — it measured 15.5px, the height of the date label alone. A percentage height against an auto-height containing block resolves to auto, and the bar has no content of its own, so every bar computed to 0px — including the tallest, which asks for 100%.

Measured in Chromium against the built app and the real API response:

daydeclaredrendered (before)rendered (after)
08-182.71%0px1.7px
08-19100%0px64.5px
08-205.65%0px3.6px
08-214.30%0px2.8px
08-222.45%0px1.6px
08-2315.91%0px10.3px
08-244.90%0px3.2px
08-2570.96%0px45.8px

Fix

The column gets h-full, and the bar moves into a flex-1 w-full flex items-end min-h-0 track that takes the space left over after the date label. The percentage now resolves against that track.

The chart keeps its 80px total height, the labels stay where they were, and a 100% bar exactly fills the track rather than overflowing — verified as 0px overflow, top and bottom.

Verification

  • Real app, not a mock: served the built dist/ with /api/* reverse-proxied to a live Nerve instance, so the numbers above come from the actual component against the actual endpoint.
  • The same measurement was run against the current main build to produce the before column.
  • Hover tooltip still works — shows 744.9K · $128.63 on the 08-19 bar, matching that DB row exactly.
  • npm run build (tsc + vite) passes.
  • Frontend: 114 tests pass.
  • Backend: 25 failed, 3256 passed, 25 errorsbyte-identical with and without this change (verified by stashing). All of it is a local env gap: 49 × ModuleNotFoundError: No module named 'mcp.server.context', unrelated to this diff.
  • eslint on the touched file: 9 problems before, 9 after — all pre-existing no-explicit-any on lines this PR does not touch.

Notes

  • Independent of web: move the panel onto the ClickHouse Click UI design system #411 — that PR does not touch DiagnosticsPage.tsx, so this branches off main and the two do not conflict. The change uses stock layout utilities only, so it holds under either token set.
  • This is the only percentage-height bar chart in the app (rg items-end finds three hits; the other two are flex-wrap toolbars), so there is no sibling instance of the bug to fix.
  • No unit test added, deliberately: vite.config.ts sets test.css: false and jsdom does not do layout, so this class of bug is invisible to the unit suite. A class-list assertion would pin the markup without testing the behaviour. The browser measurement above is the regression evidence.

🤖 Generated with Claude Code

The "Daily cost" chart rendered as bare date labels with no bars.
Each bar carries style={{ height: `${heightPct}%` }}, but its parent
column was a flex item in an `items-end` row, so the column's cross
size was content-based. A percentage height against an auto-height
containing block resolves to `auto`, and the bar has no content of its
own, so every bar computed to 0px -- including the tallest one, which
asks for 100%.
The column is now h-full, and the bar sits in a `flex-1 min-h-0` track
that takes the space left over after the date label. The percentage
resolves against that track, so the chart keeps its 80px total height
and the labels stay put.
Measured in Chromium against the built app and the real /api/diagnostics
response (8 days): bars were 0px across the board, and are now 1.6-64.5px
in proportion to cost. The hover tooltip still shows on the bar.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for freeto 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.

1 participant

@alex-clickhouse