Query is running but nothing in query_events or dc_errors

First place to check is the SESSIONS table to identify the transaction ID and statement ID. Then, using the transaction ID and statement ID, check whether the query is acquiring resources in RESOURCE_ACQUISITIONS, and if it is taking resources, you should find query activity in EXECUTION_ENGINE_PROFILES. If nothing is happening, check RESOURCE_QUEUES to see if the query is waiting, and RESOURCE_REJECTIONS to see if resources were not granted.

Thanks, Bryan, unfortunately there's nothing for our query in resource_acquisitions and it is not in resource_queues or resource_rejections. Here's what we got

dbadmin=> select start_timestamp, request_duration, is_executing, success, transaction_id from query_requests where request ilike '%table host_daily%' and user_name ='our_data_user' order by 1 desc;
start_timestamp | request_duration | is_executing | success | transaction_id
-------------------------------+------------------+--------------+---------+--------------------
2025-08-28 14:31:05.278021+00 | | t | | 108086391077821680

So this is our query, it is executing right now, notice the start timestamp.

dbadmin=> select * from resource_acquisitions where transaction_id='108086391077821680';
node_name | transaction_id | statement_id | request_type | pool_id | pool_name | thread_count | open_file_handle_count | memory_inuse_kb | queue_entry_timestamp | acquisition_timestamp | release_timestamp | duration_ms | is_executing
-----------+----------------+--------------+--------------+---------+-----------+--------------+------------------------+-----------------+-----------------------+-----------------------+-------------------+-------------+--------------
(0 rows)

Nothing in resource_acquisitions for that transaction id.

dbadmin=> select * from resource_queues;
node_name | transaction_id | statement_id | pool_name | memory_requested_kb | priority | position_in_queue | queue_entry_timestamp
-----------+----------------+--------------+-----------+---------------------+----------+-------------------+-----------------------
(0 rows)

Nothing in resource queues

dbadmin=> select * from resource_rejections order by last_rejected_timestamp desc limit 1;
node_name | pool_id | pool_name | reason | resource_type | rejection_count | first_rejected_timestamp | last_rejected_timestamp | last_rejected_value
------------------------+-------------------+-----------+-----------------------------+---------------+-----------------+-------------------------------+-------------------------------+---------------------
v_*****_node0015 | 45035996273707290 | data_pool | Request exceeded high limit | Memory(KB) | 160 | 2025-02-11 04:05:15.987216+00 | 2025-08-28 14:28:45.212019+00 | 26214401

the latest resource rejection occured at 14:28, ie three minutes before our query started, so no resource rejections for our query.

dbadmin=> select * from execution_engine_profiles where transaction_id='108086391077821680';
node_name | user_id | user_name | session_id | transaction_id | statement_id | plan_id | operator_name | operator_id | baseplan_id | path_id | localplan_id | activity_id | resource_id | counter_name | counter_tag | counter_value | is_executing
-----------+---------+-----------+------------+----------------+--------------+---------+---------------+-------------+-------------+---------+--------------+-------------+-------------+--------------+-------------+---------------+--------------
(0 rows)

Nothing in execution engine profiles for our query.

So what is going on with it?

Do other queries from MSTR work? It's just this one that times out without result or activity?
Other places to check include the internal system tables, specifically:
v_internal.vs_execution_engine_profiles
v_internal.vs_execution_engine_resources
If the query is not there and other MSTR queries work, this will require a support case to investigate.

Thanks, I will check those other tables as well. Appreciate your help, Bryan!
Other queries work. Even this query sometimes works, ie starts writing to query_events and execution_engine_profiles. But most of the time it just gets stuck like that with no evidence as to why.