ADA-C01 Question 263
Single answerTroubleshoot task historical runsA Snowflake administrator is investigating why a production root task did not execute its downstream task graph at the expected time during the last 24 hours. The administrator needs to determine whether the root task was skipped because its WHEN condition evaluated to FALSE, whether it failed during execution, or whether a child task was blocked by an upstream dependency. Which approach will provide the most complete troubleshooting information from task run history?
- A
Query INFORMATION_SCHEMA.TASK_HISTORY for the root task and all child tasks over the time window, and review STATE, QUERY_ID, ERROR_CODE, ERROR_MESSAGE, SCHEDULED_TIME, and ROOT_TASK_ID to correlate the graph execution.
- B
Run SHOW TASKS in the database and compare the current definitions of the root and child tasks to identify which task instance failed in the last 24 hours.
- C
Use DESCRIBE TASK on the root task to determine whether the most recent run was skipped by a WHEN condition or whether a child task was blocked by an upstream dependency.
- D
Query QUERY_HISTORY only for statements executed by the task owner role, because every skipped or blocked task instance generates a query that can be correlated to the task graph.
Show answer and explanation
Correct answer: A
Explanation
To troubleshoot task historical runs in Snowflake, administrators should start with TASK_HISTORY, typically through the Information Schema table function or related account usage views depending on scope and retention needs. TASK_HISTORY is designed to show execution-level outcomes, including whether a task succeeded, failed, or did not proceed as expected, along with scheduling and error details. In task graphs, reviewing only the root task is often insufficient; the administrator should inspect both the root and child tasks over the relevant time window to understand graph behavior and dependency effects. SHOW TASKS and DESCRIBE TASK are useful for validating current configuration, but they do not replace execution history. QUERY_HISTORY is valuable for deeper query-level investigation when a task actually ran and produced a QUERY_ID, but it does not cover skipped or blocked situations comprehensively. This aligns with Snowflake best practice: use task history views/functions first for execution troubleshooting, then drill into query history only when a run generated a query.
- A. Correct.
Correct. INFORMATION_SCHEMA.TASK_HISTORY is the primary source for troubleshooting historical task runs. It returns per-run details such as task state, scheduled time, query ID when a query actually ran, and error information. By reviewing the root task and its descendants together, an administrator can distinguish between skipped runs, execution failures, and downstream dependency effects. Correlating on the task graph context, including the root task relationship and time window, is the most effective way to troubleshoot what happened in a specific run sequence.
- B. Incorrect.
Incorrect. SHOW TASKS is useful for listing task objects and inspecting current metadata such as schedule, warehouse, predecessor relationships, and state, but it does not provide historical run-level execution results. A candidate might choose this because task definitions are relevant to troubleshooting, but current definitions alone cannot prove whether a particular run was skipped, failed, or never triggered.
- C. Incorrect.
Incorrect. DESCRIBE TASK returns object definition details for a single task, not historical execution records. It can help verify the configured WHEN condition or predecessors, but it cannot tell you what happened during a past run in the last 24 hours. The misconception is assuming object metadata includes execution history.
- D. Incorrect.
Incorrect. QUERY_HISTORY is incomplete for this use case because not every task state results in an executed query. For example, a skipped task due to a WHEN condition or a task that never ran because an upstream dependency was not satisfied may not have a query entry to analyze. QUERY_HISTORY can supplement troubleshooting when a QUERY_ID exists, but it is not sufficient as the primary source for all task historical states.