refactor: clean-up error handling on task execution #1400
No reviewers
Labels
No labels
FreeBSD
Kind/Breaking
Kind/Bug
Kind/Chore
Kind/DependencyUpdate
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Windows
linux-powerpc64le
linux-riscv64
linux-s390x
run-end-to-end-tests
run-forgejo-tests
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
forgejo/runner!1400
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "mfenniak/forgejo-runner:refactor-task-errors"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The goal I had in mind was to make sure that once the runner has a task from
FetchTask, it never has any error cases that don't get reported back to the server. I believe that's already practically the case, but I've applied a couple refactorings to clarify it:Run()no longer returns an error, to indicate that its expected to handle errors internally. Nearly no code paths used this.runningTasks(the only code path using the above) had a possibility for a race condition which could allow two instances of the same task to be run, which was fixed up.recover()is used when running jobs in a way that would not report status back to the server. But practically speaking theserecover()blocks were never used because panics from within the job invocation are also recovered.So, I think this just ends up as a refactor that removes some unused error handling, but it helps clarify that no error cases seem to exist that won't report status.
883d47c9e6071fe7c233071fe7c2333a5575be1fVery nice simplification.