Configure automatic retry for failed runs
Nobody has claimed this yet.
- Dominant language
- Elixir
- Stars
- 296
- Forks
- 86
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 50
Description
Goal:
- 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
- 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:
- Automatic retries should not apply for manual runs i.e. if I triggered a run myself
- 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
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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