OpenFn / OpenFn/lightning

Configure automatic retry for failed runs

Open
#2,932 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

new feature
Dominant language
Elixir
Stars
296
Forks
86
Avg merge
1d 13h
Merged PRs (30d)
50

Description

Goal:
  1. Make developers only worry about truly broken work orders

KPI: Consultant NPS

Problem/Observation

There are times when a work order fails for some external reasons (which can also be temporary) and project users who have configured their projects to send failure alerts receive an email.

Users can manually retry their runs via the history page, but they can't set it to work automatically.

The factors causing the failed run attempt might include app crashes, rate-limiting errors, or validation errors and would not require users to rewrite/refactor their code for a fix.

In this case, we want users to be able to configure work orders of a workflow in their project to automatically retry by specifying the number of retries.

What to be done:

Via the workflow configuration, I would love to be able to

  1. Configure my workflow to allow automatic retries by:
    a. Toggling it on
    b. Setting the number of times it should retry
    c. Setting the retry delay period.

When retry is enabled for a workflow:

  1. Automatic retries should not apply for manual runs i.e. if I triggered a run myself
  2. I should receive an email:
    a. when the job fails (the regular failure alerts) and retries have all failed
    b. When the retry is successful (It would be great to see which attempt succeeded)
    c. If the final retry fails
Image

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or entry points are named. Trace the workflow configuration, run history/manual-run behavior, and failure-alert email paths first; done means configurable retry enablement, count, and delay, with manual runs excluded and the specified success and final-failure notifications sent.

Written by the indexing model from the issue text.

Assessment

Tech stack
elixir
Domain
full-stack
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.