feat(dashboards): Validate display type against dataset config#115951
Conversation
Reject widget create/update requests whose (widget_type, display_type) combination isn't allowed by the frontend Widget Builder's type selector (e.g. table on tracemetrics, table on preprod-app-size).
- Add SERVER_TREE to SPANS config to match frontend spans dataset config. - Reset widget_type on context every to_internal_value so stale values don't leak between widgets when the serializer is used with many=True.
The AI Agents Overview prebuilt config omits widget_type for the traces table widget, so create_widget defaults it to error-events. Subsequent PUTs round-trip widget_type=error-events alongside the agents_traces_table display type, which would otherwise fail the new dataset validation.
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.
Reviewed by Cursor Bugbot for commit 08d107b. Configure here.
error-events is the create_widget default whenever a request omits widget_type, so any system/legacy display type from a prebuilt config that lacks widget_type ends up here (e.g. AGENTS_TRACES_TABLE from the AI Agents Overview dashboard). Removing the config entry lets the existing "no config = skip" branch handle it.
| # ERROR_EVENTS is intentionally omitted: it's the ``create_widget`` default | ||
| # when a request omits widget_type, so any system display type a prebuilt | ||
| # config doesn't tag will land here. Without a config entry the validation | ||
| # falls through and lets the request pass. |
There was a problem hiding this comment.
If it's not tagged, and defaults to ERROR_EVENTS, then imo we should just treat it with the error events config constraints instead of allowing the request to skip this check
There was a problem hiding this comment.
That's true, I can do that as a followup!
There's there's some widget types we used for prebuilt dashboards that don't have the dataset defined, such as RAGE_AND_DEAD_CLICKS which means when they save they will get error_events. It's technically not a error events widget though, so we'll have to go through these cases and see what the best path forward is, maybe we just need a widgetType for non-dataset widget and run a migration.

Rejects widget create/update requests whose
(widget_type, display_type)combination isn't allowed by the frontend Widget Builder's type selector (e.g.tableontracemetrics,tableonpreprod-app-size). Allowed combinations live in a newDATASET_CONFIGmap keyed bywidget_type.Adding the dataset configs also sets us up nicely for more per dataset validation
For example, in the ui trace metrics don't support tables, so we shouldn't let them be saved as tables