Avoid crash when removing job which might not exist in async_.py #991
Conversation
I found a scenario once though harder to reproduce that scheduler crashes when a job runs longer than the schedule which has an interval of say 1 minute. I believe the duration is lesser important, but it is possible that the job runs longer than 1 minute and when the time comes to remove it then it do not exist and calling python `set.remove(id)` crashes the scheduler which should not be so. Hence protecting it.
|
I don't think this is a fix. You're just skipping the problem. |
I concur. @neeraj9 I don't remember if I've fixed this in master yet – have you verified that it still occurs there? |
|
In principle I agree that this does hide the issue, so it should be logged and fixed appropriately. Having said that its worse to crash because restarting scheduler in a fastapi setup is non-trivial (at least for me when I have not spent much time with apscheduler). |
I have not tested with master directly, but got an error with version 4.0.0a5 available from pip. |
|
The master branch contains tons of fixes not in the latest alpha version. I wanted to release a beta back in July already but got sidetracked by other projects, plus there was an influx of bug reports which I needed to fix first. |
|
I just checked and the error no longer occurs for me on the master branch. I even commented on the issue: #952 (comment) |
|
Yup, closing as redundant. |
I found a scenario once though harder to reproduce that scheduler crashes when a job runs longer than the schedule which has an interval of say 1 minute. I believe the duration is lesser important, but it is possible that the job runs longer than 1 minute and when the time comes to remove it then it do not exist and calling python
set.remove(id)crashes the scheduler which should not be so. Hence protecting it.Changes
Fixes #.
Checklist
If this is a user-facing code change, like a bugfix or a new feature, please ensure that
you've fulfilled the following conditions (where applicable):
tests/) added which would fail without your patchdocs/, in case of behavior changes or newfeatures)
docs/versionhistory.rst).If this is a trivial change, like a typo fix or a code reformatting, then you can ignore
these instructions.
Updating the changelog
If there are no entries after the last release, use
**UNRELEASED**as the version.If, say, your patch fixes issue #999, the entry should look like this:
* Fix big bad boo-boo in the async scheduler (#999 <https://github.com/agronholm/apscheduler/issues/999>_; PR by @yourgithubaccount)If there's no issue linked, just link to your pull request instead by updating the
changelog after you've created the PR.