fix(dashboards): Default axisRange to auto for existing widgets in builder#109598
fix(dashboards): Default axisRange to auto for existing widgets in builder#109598
Conversation
…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>
There was a problem hiding this comment.
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.
static/app/views/dashboards/widgetBuilder/utils/convertWidgetToBuilderStateParams.ts
Show resolved
Hide resolved
| thresholds: widget.thresholds ? serializeThresholds(widget.thresholds) : undefined, | ||
| traceMetric: traceMetric ? serializeTraceMetric(traceMetric) : undefined, | ||
| axisRange: getAxisRange(widget.axisRange), | ||
| axisRange: getAxisRange(widget.axisRange) ?? 'auto', |
There was a problem hiding this comment.
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>
…nto edit call site" This reverts commit f6a68c7.
…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>
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
axisRangeto'auto'when loading an existing widget into the builder. This wayundefinedin builder state unambiguously means "new widget, apply dataset defaults" — existing widgets get an explicit value that matches their current rendering.dataMinfor mobile app size)axisRange: no changeRefs EME-890