villebro commented on code in PR #43942:
URL: https://github.com/apache/superset/pull/43942#discussion_r3953037985
##########
superset/daos/query.py:
##########
@@ -78,6 +78,25 @@ def stop_query(client_id: str) -> None:
)
return
+ # An async query runs as a GTF task (superset.sql_lab, keyed by
client_id).
+ # Cancel through GTF so stopping from SQL Lab and from the Task List
view are
+ # the same operation: the task's abort handler kills the warehouse
query and
+ # the task mirrors STOPPED onto the Query row.
+ from superset.commands.tasks.cancel import CancelTaskCommand
+ from superset.daos.tasks import TaskDAO
+ from superset.tasks.sql_queries import SQL_LAB_TASK
+
+ user_id = get_user_id()
+ task = (
+ TaskDAO.find_by_task_key(SQL_LAB_TASK, client_id, "private",
user_id)
+ if user_id is not None
+ else None
+ )
+ if task is not None:
+ CancelTaskCommand(task.uuid).run()
+ return
Review Comment:
Fixed in `67667a25fd`. `QueryDAO.stop_query` now marks the `Query` STOPPED
after `CancelTaskCommand` on the GTF path — a PENDING task aborts straight to
ABORTED with no worker to mirror status, and for a running task this is also
what the cooperative between-block check keys off (idempotent with the task
body’s own mirror). Added a test asserting the row becomes STOPPED.
##########
superset/daos/query.py:
##########
@@ -78,6 +78,25 @@ def stop_query(client_id: str) -> None:
)
return
+ # An async query runs as a GTF task (superset.sql_lab, keyed by
client_id).
+ # Cancel through GTF so stopping from SQL Lab and from the Task List
view are
+ # the same operation: the task's abort handler kills the warehouse
query and
+ # the task mirrors STOPPED onto the Query row.
+ from superset.commands.tasks.cancel import CancelTaskCommand
+ from superset.daos.tasks import TaskDAO
+ from superset.tasks.sql_queries import SQL_LAB_TASK
+
+ user_id = get_user_id()
+ task = (
+ TaskDAO.find_by_task_key(SQL_LAB_TASK, client_id, "private",
user_id)
+ if user_id is not None
+ else None
+ )
+ if task is not None:
+ CancelTaskCommand(task.uuid).run()
+ return
Review Comment:
Good catch — fixed in `67667a25fd`: the pending→aborted cancellation path
now marks the associated `Query` STOPPED (and sets `end_time`) so clients stop
polling. Test added (`test_query_dao_stop_query_via_gtf_task`).
##########
UPDATING.md:
##########
@@ -24,6 +24,16 @@ assists people when migrating to a new version.
## Next
+### SQL Lab query execution re-platformed onto the Global Task Framework
(breaking)
+
+SQL Lab no longer runs queries on its own bespoke Celery task. Query execution
now goes through the unified SQL execution feature (`superset/sql/execution/`):
synchronous requests run it inline, and **asynchronous** requests run it as a
Global Task Framework (GTF) task (`superset.sql_lab`, one task per query). As a
result an executing async SQL Lab statement appears in the Task List and is
cancellable from there, and stopping a query (SQL Lab's Stop button / `POST
/api/v1/query/stop`) routes through the native GTF cancel.
+
+Breaking changes (no deprecation window):
+
+- **Async SQL Lab execution now requires the `GLOBAL_TASK_FRAMEWORK` feature
flag.** With it disabled, a request that asks to run asynchronously returns a
clear error rather than executing; synchronous execution is unaffected and
needs no feature flag. (Async also continues to require a configured
`RESULTS_BACKEND` and Celery workers, as before.)
Review Comment:
Updated in `67667a25fd`. The async-queries-celery guide (and the kubernetes
/ alerts-reports / cache Celery examples) now drop the removed
`sql_lab.get_sql_results` task_annotations, point `imports` at
`superset.tasks.sql_queries`, and add a note that asynchronous SQL Lab
execution now runs on GTF and requires the `GLOBAL_TASK_FRAMEWORK` feature flag
(plus Celery + a results backend). UPDATING.md already documents the same.
--
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]
