Skip to content

fix(dashboards): Default axisRange to auto for existing widgets in builder#109598

Merged
mtopo27 merged 6 commits intomasterfrom
mtopo27/fix-axis-range-existing-widgets
Feb 27, 2026
Merged

fix(dashboards): Default axisRange to auto for existing widgets in builder#109598
mtopo27 merged 6 commits intomasterfrom
mtopo27/fix-axis-range-existing-widgets

Conversation

@mtopo27
Copy link
Contributor

@mtopo27 mtopo27 commented Feb 27, 2026

When editing an existing widget that was saved before the axisRange feature (#109390), the builder showed the dataset default (e.g. "Fit to data" for mobile app size) as checked, even though the widget was actually rendering with auto (Y-axis starting at 0). This created a mismatch between the builder UI and the actual chart behavior.

The fix normalizes missing axisRange to 'auto' when loading an existing widget into the builder. This way undefined in builder state unambiguously means "new widget, apply dataset defaults" — existing widgets get an explicit value that matches their current rendering.

  • Existing widgets: builder shows unchecked, matching actual rendering
  • New widgets: dataset default still applies (e.g. dataMin for mobile app size)
  • Existing widgets with explicit axisRange: no change

Refs EME-890

…ilder

When editing an existing widget that was saved before the axisRange
feature, the builder showed the dataset default (e.g. dataMin for
mobile app size) as checked, even though the widget was actually
rendering with auto. Normalize missing axisRange to 'auto' at load
time so the builder accurately reflects current rendering behavior.
New widgets still get the dataset default applied.

Refs EME-890
Co-Authored-By: Claude <noreply@anthropic.com>
@linear
Copy link

linear bot commented Feb 27, 2026

@mtopo27 mtopo27 marked this pull request as ready for review February 27, 2026 19:30
@mtopo27 mtopo27 requested a review from a team as a code owner February 27, 2026 19:30
@github-actions github-actions bot added the Scope: Frontend Automatically applied to PRs that change frontend components label Feb 27, 2026
Copy link
Contributor

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

thresholds: widget.thresholds ? serializeThresholds(widget.thresholds) : undefined,
traceMetric: traceMetric ? serializeTraceMetric(traceMetric) : undefined,
axisRange: getAxisRange(widget.axisRange),
axisRange: getAxisRange(widget.axisRange) ?? 'auto',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: New widgets created from templates incorrectly default to axisRange: 'auto', overriding dataset-specific defaults like 'dataMin' and causing incorrect Y-axis rendering.
Severity: MEDIUM

Suggested Fix

Modify the logic to differentiate between editing an existing widget and creating a new one from a template. For new widgets from templates, axisRange should remain undefined in the builder state to allow the dataset-specific default to be applied during the final widget conversion. The 'auto' default should only apply to existing widgets being edited.

Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location:
static/app/views/dashboards/widgetBuilder/utils/convertWidgetToBuilderStateParams.ts#L79

Potential issue: The logic in `convertWidgetToBuilderStateParams` now sets `axisRange`
to `'auto'` if it's initially `undefined`. This affects new widgets created from
templates, as they don't have an `axisRange` property. Consequently, the builder state
becomes `axisRange: 'auto'`. When converting back, this `'auto'` value is preserved,
preventing the widget from inheriting the intended dataset-specific default axis range
(e.g., `'dataMin'`). This results in new widgets rendering with an incorrect Y-axis that
starts at 0 instead of the dataset's default.

Did we get this right? 👍 / 👎 to inform future reviews.

…d test

getDefaultWidget now includes the dataset config's axisRange so new
widgets created via direct navigation get the correct default.

Also adds a test confirming that an explicit 'auto' axisRange on a
dataset with a 'dataMin' default is preserved, not overridden. This
covers the scenario where an existing widget is edited and re-saved
without touching the axis range checkbox.

Refs EME-890
Co-Authored-By: Claude <noreply@anthropic.com>
…params

constructAddQueryToDashboardLink calls convertWidgetToBuilderStateParams
which now always includes axisRange. Update the three strict toEqual
assertions to include the new field.

Refs EME-890
Co-Authored-By: Claude <noreply@anthropic.com>
… call site

The shared converter was injecting axisRange: 'auto' for every caller,
breaking discover tests that don't expect it. Move the default to the
only call site that needs it: editing an existing widget in detail.tsx.

Co-Authored-By: Claude <noreply@anthropic.com>
mtopo27 and others added 2 commits February 27, 2026 15:39
…e in query params

convertWidgetToBuilderStateParams now always includes axisRange.
Update the four strict toEqual assertions to include the new field.

Co-Authored-By: Claude <noreply@anthropic.com>
@mtopo27 mtopo27 merged commit 01217a6 into master Feb 27, 2026
68 of 70 checks passed
@mtopo27 mtopo27 deleted the mtopo27/fix-axis-range-existing-widgets branch February 27, 2026 21:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Scope: Frontend Automatically applied to PRs that change frontend components

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants