fix(dashboard,report): honor the declared percent scale so a ratio of 1 renders as 100.0% (#3136) - #3140
Merged
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
… 1 renders as 100.0% (#3136) A measure declared `format: '0.0%'` rendered every ratio below 1 correctly and got the most consequential one wrong: exactly `1` printed as "1.0%". On an SLA dashboard that reports "everything met the SLA" as "1% met the SLA", on both surfaces the issue names — they share `formatMeasure`. The multiplier was never wrong; the fact was missing. `formatMeasure` scaled by magnitude (`percentDisplayValue` multiplies only strictly inside (-1, 1)) because the column arrived with a `%` format and nothing saying what scale its numbers were on — undecidable at 1, which is both a full-compliance ratio and one percentage point. The server now says which it is (framework: `percentScale` on the result column, the sibling of the ADR-0053 currency chain). `formatMeasure` takes it as a fourth argument and scales by it when present — `fraction` x100, `whole` verbatim — instead of inspecting the value. Every dataset-bound call site passes the column's `percentScale`: dashboard metric/table/pivot, the report renderer's cells/totals/KPI, and the dataset preview. `percentDisplayValue` is untouched and remains the fallback for columns that arrive without the annotation, so nothing that renders correctly today changes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
2 participants
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.
Fixes #3136 (Console half). Server half: objectstack-ai/objectstack#4442 — merge that first;
formatMeasurereads a result-column field it adds.The bug
A dataset measure declared
format: '0.0%'rendered every ratio below 1 correctly and got the single most consequential one wrong: a rate of exactly1printed as1.0%. On an SLA / pass-rate dashboard that turns "everything met the SLA" into "1% met the SLA" — on both surfaces the issue names, since the KPI card and the dataset table shareformatMeasure(DatasetWidget.tsx:403 and :557).The cause was never a bad multiplier; it was a missing fact.
formatMeasurescaled by magnitude —percentDisplayValuemultiplies by 100 only strictly inside(-1, 1)— because the column arrived carrying a%format string and nothing saying what scale its numbers were on. That guess is undecidable at exactly 1, which is both a full-compliance ratio and one percentage point, and it resolved to the reading almost nobody intends.Worth noting what the issue's option 3 (
<= 1) would have bought: it fixes this value and leaves the guess in place for the next one. The guess is the defect.The fix
The server now answers the question instead —
percentScaleOf+AnalyticsResult.fields[].percentScale, built as the sibling of the ADR-0053 currency chain that already walks back to the source field for exactly this class of display fact. Aderived: { op: 'ratio' }measure is afractionby definition; a measure over apercentfield inherits that field's scale.formatMeasuretakes the declared scale as a fourth argument and, when present, scales by it —fraction×100,wholeverbatim — instead of inspecting the value. Every dataset-bound call site passes the column'spercentScale: dashboard metric / table / pivot cells, the report renderer's cells, row and column totals, grand total and single-value KPI, and the Studio dataset preview.percentDisplayValueis untouched and remains the fallback for a column that arrives without the annotation — an older server, or a non-dataset percent cell in a list view. Nothing that renders correctly today changes.Verification
Console dev server running this branch's
src, proxied to a real showcase backend on the framework branch, Revenue Pulse dashboard. A/B in one running UI by intercepting the response:percentScalestripped from the response (pre-fix server)Rendered DOM:
["Paid", "3", "3", "100.0%"]. The issue's second observation — a0ratio rendering as—in the table — is fixed on the server side in the linked PR (an empty filtered group is a measured zero for a count); that row now reads0/0.0%.Tests:
dataset-format12 passed (declared scale beats the heuristic in both directions; non-percent formats ignore it),DatasetWidget42 passed (new case asserts value1renders100.0%on the KPI card and the table, and a measured0stays0.0%), 254 passed across the 30 files touching these paths.@object-ui/coretypecheck clean.Considered and not taken: dropping the metric card's
?? 0at DatasetWidget.tsx:400, which fabricates a0for an absent value while the table beside it shows—. Two existing tests pin that as a deliberate choice ("shows 0, not 'No rows', for a metric over an empty dataset"), and with the server now reporting real zeros as0the surfaces agree on every measured value. Reversing it deserves its own discussion.🤖 Generated with Claude Code