0 0
Read Time:1 Minute, 48 Second

RETRY LAST: In modern data workflows, tasks are often interdependent, forming complex task chains. Ensuring the reliability and resilience of these workflows is critical, especially when dealing with production data pipelines. Imagine you’re tasked with managing a critical data pipeline in Snowflake that processes and transforms large datasets. This pipeline consists of several sequential tasks:

  1. Task A: Loads raw data into a staging table.
  2. Task B: Transforms the data in the staging table.
  3. Task C: Aggregates the transformed data (simulates a potential failure).
  4. Task D: Loads the aggregated data into the final table.

These task are chained together using Snowflake tasks, ensuring they run in the correct order. However, what happens if a task fails in the middle of the pipeline?

Snowflake’s RETRY LAST feature allows us to automate the retry mechanism for failed task, ensuring minimal downtime and continuous data processing.

In this use case, we will demonstrate how to monitor and retry a chain of Snowflake tasks programmatically using a JavaScript stored procedure. This procedure will identify the root task and handle task failures by retrying from the last failed state.

Technical Implementation:

Retry Last Task

It automates the process of recovering from task failures:

  1. Identifying the Root Task: The procedure retrieves information about all scheduled tasks using SHOW TASKS. It then iterates through the tasks and identifies the “root task” – the one without any predecessors, marking the beginning of the pipeline.
  2. Checking for Failed Tasks: It then queries the TASK_HISTORY view to check for any recently failed tasks within the pipeline.

Automatic Retry: If a failure is detected, the procedure leverages the EXECUTE TASK command with the RETRY LAST option. This intelligently retries only the failed task (Task C in this case) and all its dependent tasks (Task D) without restarting the entire pipeline from scratch


  • Schedule the Procedure: Schedule the procedure to run periodically (e.g., every minute) to proactively monitor for task failures.
  • Customize Failure Handling: The procedure currently retries the failed task and its dependents. You can modify it to handle failures differently, such as sending notifications or logging errors for further investigation.

Average Rating

5 Star
4 Star
3 Star
2 Star
1 Star

Leave a Reply

Your email address will not be published. Required fields are marked *