[rebenitez1802]

SUMMARY

On Impala, pressing Stop while SQL Lab was reading a query's results marked the query stopped, but Impala kept executing it and held its admission slot until it finished. UPDATING.md listed this as a known gap of #45232.

This is the common case for a long SELECT, not an edge case. Impala reports a streaming SELECT as FINISHED as soon as its rows can be fetched: about 0.1 s after submission on Impala 4.5.2, with or without result spooling. handle_cursor then stops polling, and the rest of the query runs while the worker is inside fetch_data. Aggregations and CTAS stay RUNNING while they work, so polling already covered them.

Changes

• Stop checks during the fetch. While it reads the results of a SQL Lab query that handle_cursor polled, fetch_data checks for a committed stop between result RPCs, at most once per DB_POLL_INTERVAL_SECONDS.
  • The stop is applied on the worker's own cursor and thread with cancel_operation(), as fix(impala): stop SQL Lab queries through the live cursor only #45232 does while polling. There is no HTTP call to the coordinator and no second connection, so it also works where the web UI is unreachable or the internal-hosts opt-out is off.
  • Impala returns each result RPC within FETCH_ROWS_TIMEOUT_MS (10 s by default) even when no rows are ready. A stop therefore takes effect within about FETCH_ROWS_TIMEOUT_MS + DB_POLL_INTERVAL_SECONDS.
• One more check when polling ends. handle_cursor checks again as it finishes. This catches a stop committed during the last poll interval, or before an operation that is already FINISHED at its first poll.
• Failed checks don't fail the query. If a stop check itself fails, for example on a metadata database error, the fetch continues: the check rolls back its transaction and the query is not failed. A time limit that fires during a check is still raised.
• The async executor reports these stops as stops. When a fetch fails because the query was stopped, the async SQLExecutor task (Database.execute_async) reports the stop. It no longer logs an unhandled ERROR with a traceback. Genuine failures keep the SQL of the statement that failed.
• Unchanged: charts, MCP and any other fetch that handle_cursor did not poll.

Known limit. Impala checks for cancellation between row batches. A single batch whose rows are slow to compute, such as an expensive function over one batch, runs to the end of that batch first. This is documented.

Overlap with draft #45845. It changes the same Impala engine spec and tests, and replaces the SoftTimeLimitExceeded import with TIME_LIMIT_EXCEPTIONS. Whichever PR lands second needs to adapt to the other.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Not applicable; there are no UI changes. Here is the backend behaviour on Impala 4.5.2, for a Stop sent 5 s into the fetch of SET BATCH_SIZE=1; SELECT sleep(1000) AS s, x FROM <200-row table>:

	Before	After
Superset outcome	stopped	stopped, no rows, no error
Impala	keeps executing the query and holds its admission slot until it finishes	stops executing the query and releases the slot

TESTING INSTRUCTIONS

Unit tests. They use a fake impyla cursor and need no driver.

pytest tests/unit_tests/db_engine_specs/test_impala.py \
  tests/unit_tests/db_engine_specs/test_impala_pending.py \
  tests/unit_tests/sql/execution/test_celery_task.py

Real cluster. These results come from the public Apache Impala 4.5.2 quickstart (docker/quickstart.yml at tag 4.5.2 of apache/impala), with PostgreSQL metadata, a separate Celery worker, IMPALA_CANCEL_QUERY_ALLOW_INTERNAL_HOSTS = False, and DB_POLL_INTERVAL_SECONDS = {"impala": 0.5}. At the default interval of 5 s, release takes up to about 5 s longer.

Path	Fetch-phase Stop (3 runs each)	Released after Stop
SQL Lab sync	stopped, 0 rows, no error	5.4–5.6 s
SQL Lab async (separate worker)	stopped	5.4–5.6 s
Database.execute_async + cancel()	STOPPED, no worker ERROR log	5.4–5.6 s

Each Stop was sent 5 s into the fetch, and Impala released the query at the end of the 10 s result RPC in flight. The following were unchanged:

• normal success on all three paths;
• a Stop while RUNNING (released within 0.4–0.7 s);
• a Stop while held in admission;
• a Stop after the query completed, which keeps its success result.

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for superset-docs-preview ready!

Name	Link
🔨 Latest commit	59959af
🔍 Latest deploy log	https://app.netlify.com/projects/superset-docs-preview/deploys/6ae3adfc31a6d4d165054e1c
😎 Deploy Preview	https://deploy-preview-45859--superset-docs-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[codecov]

Codecov Report

❌ Patch coverage is 89.04110% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 84.70%. Comparing base (65db213) to head (59959af).

Files with missing lines	Patch %	Lines
superset/db_engine_specs/impala.py	88.40%	6 Missing and 2 partials ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #45859   +/-   ##
=======================================
  Coverage   84.70%   84.70%           
=======================================
  Files        3069     3069           
  Lines      205597   205665   +68     
  Branches    48327    48334    +7     
=======================================
+ Hits       174148   174208   +60     
- Misses      28157    28163    +6     
- Partials     3292     3294    +2     

Flag	Coverage Δ
hive	34.50% <17.80%> (-0.01%)	⬇️
mysql	52.57% <17.80%> (-0.03%)	⬇️
postgres	52.57% <17.80%> (-0.03%)	⬇️
presto	36.23% <17.80%> (-0.02%)	⬇️
python	87.75% <89.04%> (+<0.01%)	⬆️
sqlite	52.34% <17.80%> (-0.03%)	⬇️
unit	82.48% <89.04%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[aminghadersohi]

Two non-blocking issues in the new stop path: unrelated failures lose their diagnostics, and the documented timeout bound disappears at zero.

[aminghadersohi]

If Stop races a real fetch or result-conversion failure (e.g. MemoryError), this handler drops its traceback and error_sqllab_unhandled metric for every engine. Preserve diagnostics for errors unrelated to cancellation.

[aminghadersohi]

FETCH_ROWS_TIMEOUT_MS=0 makes fetch requests wait indefinitely, so lowering it to zero can prevent Stop from being observed until the fetch returns. The tuning guidance needs to require a positive value.

Suggested change

	RPC returns within Impala's `FETCH_ROWS_TIMEOUT_MS` query option (10 seconds by
	default, available from Impala 3.4) even when no rows are ready, so a stop takes
	effect within about `FETCH_ROWS_TIMEOUT_MS` plus `DB_POLL_INTERVAL_SECONDS`;
	lowering either makes stops take effect sooner. Impala checks for cancellation between row batches, so a batch whose
	RPC returns within Impala's `FETCH_ROWS_TIMEOUT_MS` query option (10 seconds by
	default, available from Impala 3.4) when it is positive, even when no rows are ready,
	so a stop takes effect within about that timeout plus `DB_POLL_INTERVAL_SECONDS`.
	Lowering a positive timeout or the poll interval makes stops take effect sooner.
	Setting `FETCH_ROWS_TIMEOUT_MS=0` disables the timeout and can delay Stop until the
	fetch returns. Impala checks for cancellation between row batches, so a batch whose