refactor(dashboards-v2): declare per-kind query capabilities instead of inferring them from panel types - #12559
Open
ahrefabhi wants to merge 5 commits into
Open
refactor(dashboards-v2): declare per-kind query capabilities instead of inferring them from panel types#12559ahrefabhi wants to merge 5 commits into
ahrefabhi wants to merge 5 commits into
Conversation
The View modal renders PanelEditorQueryBuilder; this component had no importers and referenced a stylesheet class that no longer exists. Assisted-by: Claude Opus 5
…a panel type The uPlotV2 axis builder decided X-axis date formatting by testing the panel type against a hardcoded [TIME_SERIES, BAR] list. A chart that plots time but is not one of those two silently lost its time-formatted ticks — no type error, no failing test, just wrong-looking ticks. Axis props now take isTimeAxis and each caller states it: the three V2 kinds through the shared base config (histogram passes false — its X axis is buckets), and the Meter Explorer, K8s metrics and V1 shared config builders directly. Assisted-by: Claude Opus 5
Each panel kind now states how its query behaves — request type, result formatting, step-interval and order treatment, paging, whether it is authored as a list view, and whether it offers a trace operator. These are the questions V2 answered by comparing against the legacy PANEL_TYPES enum. Declaring them per kind means the compiler asks for an answer when a kind is added, instead of the kind silently falling through someone else's switch. The expectations are an exhaustive Record over PanelKind, so a new kind cannot ship without stating its request shape. getPanelDefinition also stops lying. It was typed to return a definition for any PanelKind, but the registry only holds the kinds this build registers — a dashboard spec written by a newer SigNoz names one it has never heard of, and callers coped by truthiness-checking a value the type said could not be falsy. An unregistered kind now resolves to UNSUPPORTED_PANEL, which declares nothing and renders as unsupported, so callers read a definition's fields directly and such a panel says why it is blank instead of leaving a hole in the layout. Whether a kind can be rendered at all becomes its own question: isPanelKindSupported. Assisted-by: Claude Opus 5
…e declarations buildQueryRangeRequest now takes the kind's declared query capabilities instead of a legacy panel type, so the request type, table formatting, bar step interval and list order tiebreaker all come from the kind itself. The editor asks the same declarations whether the query builder runs in list-view mode, offers a trace operator, shows the plot-mode chip, or seeds a default query, rather than testing "is this the List panel?" in four places. The capabilities are passed in rather than looked up by kind: the panel registry carries every renderer with it, which has no business in the data path — importing it there pulls the app's API client into any test that touches the request builder. The call sites already resolve the definition, so threading it costs nothing. PlotTag takes isListView instead of a panel type, so a presentational component no longer needs the enum at all. panelTypeToRequestType moves to persesQueryAdapters, the V1 Query pivot that is now its only caller — the legacy switch belongs on the V1 side of the boundary rather than in the middle of the V5 request builder. The shared QueryBuilderV2 provider keeps its legacy panelType prop: that is state inside the shared provider, read by its subcomponents, and out of scope here. Assisted-by: Claude Opus 5
Panel events identified the panel only by its legacy panel type, which cannot tell apart two kinds that map onto the same one — so a newly added kind is indistinguishable from the kind it shares a type with. Adds panelKind alongside the existing panelType on all seven events (no data, clone, delete, move, CSV export, drilldown opened, create alert). Additive on purpose: existing reports keep resolving. Assisted-by: Claude Opus 5
ahrefabhi
force-pushed
the
refactor/v2-panel-query-capabilities
branch
from
August 14, 2026 09:25
7ae53e5 to
98d2da9
Compare
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
1 participant
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.
Description
V2 panels answered "how does this panel's query behave?" by comparing against the legacy
PANEL_TYPESenum. Each kind now declares it, so adding a kind means stating its behaviour once instead of finding every switch that should have mentioned it.buildQueryRangeRequesttakes that block, so thePANEL_TYPES.BAR/.LIST/.TABLEbranches are gone. An exhaustiveRecord<PanelKind, …>test means a new kind can't ship without declaring its request shape.UPlotAxisBuilderdecided X-axis date formatting from a hardcoded[TIME_SERIES, BAR]list, so a chart that plots time but isn't one of those two silently lost its formatted ticks — no type error, no failing test. Callers now declareisTimeAxis.getPanelDefinitionalways resolves. It was typed to return a definition for anyPanelKind, but the registry only holds registered kinds, and a spec from a newer SigNoz names one this build has never heard of. Callers coped by truthiness-checking a value the type said couldn't be falsy — a lint autofix had already deleted one such guard inPublicPanel. Unknown kinds now resolve toUNSUPPORTED_PANEL, which declares nothing and renders as unsupported;isPanelKindSupportedis the separate question the lazy fetch and editor session actually needed.panelKindon all seven panel events, alongside the existingpanelTypeso current reports keep resolving.panelTypecan't distinguish two kinds that map onto it.ViewPanelQueryBuilder— no importers; the View modal rendersPanelEditorQueryBuilder. It referenced a stylesheet class that no longer exists.Behaviour is unchanged for every registered kind. The one visible difference: a panel whose kind this build can't render now says so, instead of rendering a header above an empty body.
Additional Information
Querypivot (mapCompositeQueryFromQuerywritespanelTypeintoICompositeMetricQuery), URL params (graphType/panelTypesare a serialised contract), the sharedQueryBuilderV2provider (wherepanelTypeis provider state read by its subcomponents), and analytics. A follow-up will quarantine those into a single boundary module with a lint rule keeping them there.resolveQueryCapabilities, added earlier in this branch: it existed only to absorb a missing definition, which the registry no longer produces.