search

agronholm / apscheduler

Task scheduling library for Python
MIT License
6.3k stars 712 forks source link

Avoid crash when removing job which might not exist in async_.py #991

Closed neeraj9 closed 1 day ago

neeraj9 commented 3 days ago

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):

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.

coveralls commented 3 days ago

Coverage Status

coverage: 92.033%. remained the same when pulling e8c5248552d71a0c280a7ba350e54a698c133a58 on neeraj9:neeraj9-patch-1-avoid-crash-in-finally into d01ad31961dd0139c8eb0ebb602ae97f16ea2744 on agronholm:master.

HK-Mattew commented 3 days ago

I don't think this is a fix. You're just skipping the problem.

agronholm commented 3 days ago

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?

neeraj9 commented 3 days ago

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).

neeraj9 commented 3 days ago

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?

I have not tested with master directly, but got an error with version 4.0.0a5 available from pip.

agronholm commented 3 days ago

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.

HK-Mattew commented 3 days ago

I just checked and the error no longer occurs for me on the master branch. I even commented on the issue: https://github.com/agronholm/apscheduler/issues/952#issuecomment-2485617250

agronholm commented 1 day ago

Yup, closing as redundant.