Set job status to dismissed in case the dismiss endpoint is called (close #174) - #175
Set job status to dismissed in case the dismiss endpoint is called (close #174)#175Florian-Katerndahl wants to merge 3 commits into
Conversation
…lose #174) - Explicitly set the `status` field for both the local backend and the airflow backend
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
Thanks for this!
Although it seems obviously correct, I don't agree with this implementation.
The job status should reflect the true status of the job and not the expected one. If a user calls "dismisses my job", this is a request. Whether it has really been dismissed is a status that must be determined. And that is what the old implementation did.
To fix this, we may wait for given timeout then get the current true state of a job and return it.
Also, I don't understand why unit tests are not applicable here! Please provide tests.
|
Thanks for the feedback, I'll add tests for revised changes. Regarding the actual status of the job: If I understand the Python documentation, there's no general way to cancel a future object without shutting down the *PoolExecutor. Thus, the solution might actually be to wait for the job to finish naturally but immediately delete the result as you suggest. |
|
@Florian-Katerndahl Once you've changed any code in this PR, please Convert to draft, then re-request a new review, work on it undtil CI is happy, and turn it back to Ready for review.. |
|
As discussed, the hard-coding of the job status remains; adapted the tests though |
2 participants
[Description of PR]
Explicitly set the
statusfield for both the local backend and the airflow backendChecklist (strike out non-applicable):
CHANGES.mdCHANGES.md* [ ] Added docstrings and API docs for any new/modified user-facing classes and functions* [ ] Changes/features documented indocs/*