[PR] fix(canopy/query): reset SELECT/GROUP BY/WHERE when the FROM resource changes [skywalking-banyandb]

["waterWang (via GitHub)" <gi...@apache.org>]

waterWang opened a new pull request, #1313:
URL: https://github.com/apache/skywalking-banyandb/pull/1313

   Fixes #14043
   
   ## Summary
   
   In the Canopy Query builder, switching the resource in the FROM row (via the resource or group dropdown) left stale clause projections behind. `setResource` patched only `resource`, and `setGroup` patched `group` + `resource`, neither touching `select` / `projection` / `where` / `groupBy`. Tags that exist only on the previous resource (e.g. `entity_id` from a Measure) remained in SELECT after switching to a Trace, producing invalid BydbQL or a confusing UI state.
   
   `onPickResource` (the fuzzy From pick) already performs the correct cascade-reset. This change applies the same reset to the dropdown handlers, independent of schema arrival (which the existing WHERE re-prune effect depends on — see maintainer analysis in #14043).
   
   ## Changes
   
   - `canopy/web/src/query/QueryBuilder.tsx`: `setResource` and `setGroup` now also clear `select`, `projection`, `where` and `groupBy`, and reset `fromAgg` / `fromResource`. WHERE is reset to an empty group, or a seeded `trace_id` condition for trace resources (mirroring `onPickResource`).
   - `canopy/web/src/query/QueryBuilder.test.tsx`: regression tests for both the resource-change and group-change paths.
   
   ## Verification
   
   - `vitest run src/query/QueryBuilder.test.tsx` — 10/10 pass (including the 2 new regression tests).
   - Full `src/query` suite: 274 passed, 4 pre-existing failures in `result-views.test.tsx` (timezone-dependent timestamp assertions, unrelated to this change).
   - `tsc --noEmit`: no new errors from the touched files.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@skywalking.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] fix(canopy/query): reset SELECT/GROUP BY/WHERE when the FROM resource changes [skywalking-banyandb]

["hanahmily (via GitHub)" <gi...@apache.org>]

hanahmily closed pull request #1313: fix(canopy/query): reset SELECT/GROUP BY/WHERE when the FROM resource changes
URL: https://github.com/apache/skywalking-banyandb/pull/1313


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@skywalking.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] fix(canopy/query): reset SELECT/GROUP BY/WHERE when the FROM resource changes [skywalking-banyandb]

["hanahmily (via GitHub)" <gi...@apache.org>]

hanahmily commented on PR #1313:
URL: https://github.com/apache/skywalking-banyandb/pull/1313#issuecomment-5434965023

   Thanks for the fix — you correctly identified the root cause of #14043.
   
   `setResource` / `setGroup` only patched the FROM fields and left stale `select` / `projection` / `where` / `groupBy` behind, while fuzzy `onPickResource` already cascade-resets. Resetting those clauses on the dropdown path (and re-seeding an empty `trace_id` WHERE for Trace) is the right primary fix for the screenshot case.
   
   We're landing the same issue via #1312, which takes a slightly broader cut for parity with fuzzy pick and persistence:
   
   1. Shared `resetResourceClauses()` (also clears Trace `orderField` and `offset`, matching `onPickResource`)
   2. Schema-load pruning in `QueryConsole` for projection / WHERE / GROUP BY / measure `select[]` (defense when state is restored or a path skips the full reset)
   3. Extracted `qbDefaultTraceWhere` / prune helpers so the Trace seed isn't duplicated
   4. Regression coverage for the Trace `entity_id` → `zipkin_span` path via generated BydbQL, plus group auto-pick / fuzzy-pick paths
   
   I'd suggest closing this PR in favor of #1312 to avoid duplicate merges. Happy to credit this analysis in the #1312 discussion — independently hitting the same root cause was valuable confirmation.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@skywalking.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org