ADA-C01 Question 262
Single answerTroubleshoot task historical runsA Snowflake administrator is investigating why a production task stopped loading data overnight. The task is part of a task graph and is owned by the ETL role. The administrator needs to determine whether the task itself failed, was skipped because an upstream dependency did not complete, or did not run because the task graph was suspended. Which action will provide the most reliable historical run details for this analysis?
- A
Query the TASK_HISTORY table function for the task and review STATE, ERROR_MESSAGE, SCHEDULED_TIME, QUERY_ID, and ROOT_TASK_ID to correlate runs across the task graph.
- B
Run SHOW TASKS and inspect the current STATE and definition of the task, because SHOW TASKS includes detailed execution history for previous runs.
- C
Query QUERY_HISTORY for the warehouse used by the task, because every skipped or suspended task creates a query entry that explains why it did not run.
- D
Use DESCRIBE TASK to review the task SQL text, because DESCRIBE TASK returns the status of prior executions and the reason each run failed or was skipped.
Show answer and explanation
Correct answer: A
Explanation
For troubleshooting historical task runs in Snowflake, administrators should use the TASK_HISTORY table function. It is specifically designed to inspect past task executions and includes status and diagnostic fields needed to determine whether a run succeeded, failed, was skipped, or was impacted by task graph behavior. In task graph scenarios, identifiers such as ROOT_TASK_ID are especially valuable for correlating related runs across parent and child tasks. SHOW TASKS and DESCRIBE TASK are useful for current metadata and configuration, but they do not provide execution history. QUERY_HISTORY is complementary when a task execution generated SQL, but it is not sufficient by itself because not every task state maps cleanly to a query record. This aligns with Snowflake documentation and best practice: use TASK_HISTORY first for task-run troubleshooting, then correlate with QUERY_HISTORY when a QUERY_ID is available.
- A. Correct.
Correct. The TASK_HISTORY table function is the primary source for troubleshooting historical task runs. It exposes execution-level details such as STATE, ERROR_MESSAGE, SCHEDULED_TIME, QUERY_ID, and graph-related identifiers like ROOT_TASK_ID, which help distinguish between a task that failed, one that was skipped, and one affected by task graph conditions. This is the most reliable historical view for analyzing previous executions.
- B. Incorrect.
Incorrect. SHOW TASKS is useful for listing task metadata such as whether a task is currently started or suspended, its schedule, and its definition. However, it does not provide detailed historical execution records for prior task runs. A common misconception is to use SHOW commands for runtime troubleshooting, but they are primarily metadata inspection tools.
- C. Incorrect.
Incorrect. QUERY_HISTORY can help investigate SQL statements that actually executed, especially if a task run produced a QUERY_ID. However, it is not the authoritative source for determining all task outcomes. Skipped runs and certain graph-level conditions may not produce a corresponding query record, so relying on QUERY_HISTORY alone can miss the reason a task did not execute.
- D. Incorrect.
Incorrect. DESCRIBE TASK returns task properties and configuration details, not a history of prior executions. It can help verify whether the task definition or warehouse assignment is correct, but it does not explain why a specific historical run failed, was skipped, or did not occur.