fix(dashboards): use null instead of undefined for widget limits on TABLE/BIG_NUMBER#112921
Open
fix(dashboards): use null instead of undefined for widget limits on TABLE/BIG_NUMBER#112921
Conversation
…ABLE/BIG_NUMBER TABLE and BIG_NUMBER widgets should never have limits, but changing a chart widget to TABLE via the builder set limit to undefined, which JSON.stringify drops. The backend then kept the stale DB value, causing "Maximum limit for this display type" errors on subsequent saves. Use null so the value survives serialization and the backend clears it. Also strengthen _enforceWidgetLimit to clear limits for TABLE/BIG_NUMBER and cap chart limits to their display-type maximum. Fixes DAIN-1330
github-actions
bot
added
the
Scope: Frontend
Contributor
Sentry Snapshot Testing
|
Follow-up to the Widget.limit type widening (number | null). Places that pass widget.limit to components or functions expecting number | undefined now use ?? undefined to coerce null.
TEXT widgets have no queries, so accessing queries[0].aggregates would crash. Add TEXT to the early-return alongside TABLE/BIG_NUMBER.
nikkikapadia
approved these changes
Apr 14, 2026
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 3 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 585bda6. Configure here.
…limit check - Add AGENTS_TRACES_TABLE to the early-return list in _enforceWidgetLimit (table-like widget was falling through to chart capping logic) - Guard against empty queries array before accessing queries[0] - Use defined() instead of !== undefined for limit check in dataWidgetViewerModal (null !== undefined is true)
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
The limit cap in _enforceWidgetLimit should only apply to chart widgets that have grouping columns, since limits are only relevant for Top N behavior. Non-grouped chart widgets should pass through unchanged.
Instead of maintaining a growing exclusion list of display types that don't use limits (TABLE, BIG_NUMBER, TEXT, AGENTS_TRACES_TABLE, WHEEL, DETAILS, SERVER_TREE, RAGE_AND_DEAD_CLICKS...), flip to an allowlist of the chart types that actually use limits: AREA, BAR, LINE, TOP_N, CATEGORICAL_BAR. Everything else gets limit cleared to null.
Document why DISPLAY_TYPES_WITH_LIMITS is an allowlist — other types either fetch their own data (see widgetFetchesOwnData) or don't use limits (TABLE, BIG_NUMBER, WHEEL, DETAILS).
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.
When a user changes a widget from a chart type (e.g., CATEGORICAL_BAR with limit=25) to TABLE via the widget builder,
convertBuilderStateToWidgetwas settinglimit: undefined. SinceJSON.stringifydropsundefinedvalues, the backend never received the limit field and kept the stale value viadata.get("limit", widget.limit). On subsequent dashboard saves (e.g., rearranging widgets), the stale limit was sent as a real number, triggering "Maximum limit for this display type is {N}" validation errors.The fix uses
nullinstead ofundefinedfor TABLE and BIG_NUMBER widget limits, so the value survives JSON serialization and the backend actually clears it. The backend serializer already hasallow_null=Trueon the limit field.I had to update a bunch of types to fall back to
undefinedifnullis provided which adds a bit of confusion. I'm feeling like maybe a cleaner approach is to actually enforce that a limit must be provided, but that seems better for a future PR.Additionally,
_enforceWidgetLimit(the safety net for dashboard-level saves like rearranging/duplicating) previously skipped TABLE/BIG_NUMBER entirely and didn't cap existing limits. It now:null)getResultsLimit)I also filed a separate ticket to harden the API against changing the widget type and preserving an illegal limit
Fixes DAIN-1330