Only error tasks if the failure is within the task implementation
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1.5k
- Forks
- 95
- Avg merge
- 4d 21h
- Merged PRs (30d)
- 1
Description
Errors like TaskImportError or errors stemming from a broken child context manager shouldn't move the task to the ERROR state - it should remain in QUEUED.
This way when we somehow break TaskTiger outside of the task implementation we don't need to worry about which tasks should be retried and make recovery far easier.
To implement this we'd need a way for the child process to signal an "abort". Currently we return exit code 0 in case of success and 1 in case of error. We could add exit code 2 to signify an abortion of task processing, in which case the parent process could move the task back into the QUEUED state.
WDYT @thomasst ?
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
Trace the child-process task handling and the parent process's task-state transition after a worker exits. Define how an abort signal, such as a distinct exit code, is propagated so failures outside the task implementation return tasks to QUEUED while task failures still use ERROR; verify both paths with the relevant worker and state-transition tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, distributed-systems
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100