X-arshiya-X opened a new pull request, #36350: URL: https://github.com/apache/superset/pull/36350
### SUMMARY <!--- Describe the change below, including rationale and design decisions --> This PR fixes Issue #35347, where the Stop button in Chart and Dashboard views did not actually stop running queries on Trino and other databases. **Previously:** - The stop button in the Explore/Chart view was not wired to the backend cancellation logic. - Chart queries were effectively stateless from the perspective of cancellation and did not carry query_id / client tracking information used by the backend to kill queries. - As a result, clicking Stop, closing the tab, refreshing the page, or navigating away would still leave the query running on the database, consuming unnecessary compute resources. **This PR:** - Adds client and query tracking for chart queries so they carry the necessary identifiers for cancellation. - Wires the chart stop button to a new backend API endpoint that uses the same query-killing logic already used by SQL Lab. - Ensures that when a user clicks Stop in Chart view, a cancellation request is sent to the backend, which then kills the corresponding running query on the database. **Key changes include:** *Frontend:* - `superset-frontend/src/components/Chart/chartAction.js` - `superset-frontend/src/components/Chart/chartReducer.ts` - `superset-frontend/src/explore/components/ExploreViewContainer/index.jsx` - `superset-frontend/src/explore/exploreUtils/index.js` - `superset-frontend/src/explore/types.ts` These changes add client/query tracking to chart queries and connect the Stop button to the new cancellation API. *Backend:* - `superset/charts/schemas.py` - `superset/common/query_context.py` - `superset/common/query_context_factory.py` - `superset/common/query_context_processor.py` - `superset/models/core.py` - `superset/models/helpers.py` These changes ensure that chart queries are created with client/query identifiers and that the backend can locate and cancel the corresponding running query. Behaviorally, there are no breaking changes: the Stop button now behaves as expected by users (similar to SQL Lab), and no existing functionality is regressed. ### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF <!--- Skip this if not applicable --> No visual UI changes. The Stop button remains the same visually; only its behavior is corrected (it now kills the backend query). **Behavioral demonstration:** - **Before:** Clicking Stop in Chart view would stop the frontend loading indicator, but the query continued running in the database (e.g., Trino), wasting resources. <img width="2486" height="1278" alt="image1" src="https://github.com/user-attachments/assets/dce87ca5-1e90-4de6-a540-fd283417b14f"; /> <img width="2486" height="1278" alt="image2" src="https://github.com/user-attachments/assets/547898f0-b06f-4940-a21c-fe485d9230c2"; /> - **After:** Clicking Stop in Chart view sends a cancellation request to the backend, which kills the query in the database. The query transitions to a cancelled/killed state (e.g., `USER ERROR: ADMINISTRATIVELY KILLED` in Trino). <img width="2546" height="1355" alt="image3" src="https://github.com/user-attachments/assets/484c2166-60ad-475f-a6a4-32a5ee26466e"; /> ### TESTING INSTRUCTIONS <!--- Required! What steps can be taken to manually verify the changes? --> 1. Set up Superset with Trino (or another supported DB where you can see running queries). 2. Start Superset and log in. 3. Go to **Explore / Create Chart** and configure a chart that triggers a long-running query (e.g., a heavy query against Trino). 4. Open the Trino UI (or the database's query monitoring UI) to observe running queries. 5. In Chart view, run the chart and confirm the query appears as running in Trino. 6. Click the **Stop** button in Chart view. 7. Verify in the Trino UI that: - The query is cancelled, and - It transitions to an error such as `USER ERROR: ADMINISTRATIVELY KILLED` (or the equivalent cancellation message for your database). 8. Repeat the above steps from a Dashboard that contains a chart to confirm that stopping from the Dashboard view also cancels the underlying query. **Additionally:** - Run the existing test suite to ensure no regressions: - `pytest` (backend) - `npm test` / `pnpm test` (frontend), as appropriate for the repo setup. - Confirm that SQL Lab query cancellation behavior remains unchanged and still works as expected (regression check). ### ADDITIONAL INFORMATION <!--- Check any relevant boxes with "x" --> <!--- HINT: Include "Fixes #nnn" if you are fixing an existing issue --> - [x] Has associated issue: Fixes #35347 - [ ] Required feature flags: - [ ] Changes UI - [ ] Includes DB Migration (follow approval process in [SIP-59](https://github.com/apache/superset/issues/13351)) - [ ] Migration is atomic, supports rollback & is backwards-compatible - [ ] Confirm DB migration upgrade and downgrade tested - [ ] Runtime estimates and downtime expectations provided - [x] Introduces new feature or API - [ ] Removes existing feature or API **Additional notes:** - No new external dependencies are introduced. - No performance concerns identified; cancelling queries should reduce unnecessary resource usage. - No DB migrations are required. - The change reuses the existing SQL Lab query cancellation mechanism, ensuring consistent behavior across SQL Lab and Explore/Chart views. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
