Task 1 – Multi-QueryState Architecture (Multiple QueryStates per Tab)

[astandrik]

Scope

• Define a tab-aware data model for SQL queries (tab id, title, query text, dirty flag, timestamps, and references to last execution/result).
• Extend the query slice (or introduce a focused queryTabs slice) to store multiple QueryStates, one per tab, while keeping existing selectors (selectUserInput, selectResult, etc.) valid for the active tab.
• Thread a tabId through the execution pipeline (useSendQuery, useStreamQuery, setQueryResult, streaming reducers) so results and execution metadata are associated with the correct tab.
• Keep session-storage behavior (QUERY_EDITOR_CURRENT_QUERY_KEY, QUERY_EDITOR_DIRTY_KEY) but make it tab-aware and backward compatible so current users do not lose their open query.
• Ensure queryManagerInstance can track and abort running queries per tab without race conditions.

Key files

• src/store/reducers/query/query.ts (or new slice under src/store/reducers/query/ for tab state and selectors).
• src/containers/Tenant/Query/QueryEditor/QueryEditor.tsx (connect active tab to editor/result and pass tabId into query execution).
• src/containers/Tenant/Query/QueryEditor/YqlEditor.tsx (switch from a single selectUserInput to per-tab input while keeping Monaco behavior and shortcuts).

Risks/constraints

• Must avoid breaking existing flows that assume a single query (e.g., history integration, setUserInput selectors, e2e tests).
• Need careful migration of QUERY_EDITOR_CURRENT_QUERY_KEY / QUERY_EDITOR_DIRTY_KEY usage so existing users keep their current query.
• Tab state must be tenant-aware and resilient to navigation (back/forward, route changes) without memory leaks.
• Query API logic today assumes a single “current” result; per-tab mapping must remain backward compatible and safe for streaming.

Acceptance criteria

• Store and switch between multiple QueryStates internally, with the active tab determining what selectUserInput/selectResult return.
• Execution results are associated with the correct tab (including streaming) without leaking across tabs.
• Existing behavior with a single tab remains unchanged from the user’s point of view.
• Unit tests cover new reducers/selectors and per-tab result association.