You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The backend.lock.file module has a bug in it that results in subsequent instances of CronJob classes being allowed to run even though ALLOW_PARALLELL_RUNS=False.
Take a look at line 20 (or 21 in 0.6.0, which is what pypi is providing):
In locks.lock(...) a BlockingIOError exception is thrown when a second (or more) instance tries to start, so it returns False, as it should. However, this return is effectively ignored (see <<< PROBLEM HERE) and the try/except block falls through to return True, which allows the instance to start regardless of the exclusion lock.
The problem line should simply return the result of locks.lock.
The text was updated successfully, but these errors were encountered:
The backend.lock.file module has a bug in it that results in subsequent instances of CronJob classes being allowed to run even though
ALLOW_PARALLELL_RUNS=False
.Take a look at line 20 (or 21 in 0.6.0, which is what pypi is providing):
In
locks.lock(...)
a BlockingIOError exception is thrown when a second (or more) instance tries to start, so it returnsFalse
, as it should. However, this return is effectively ignored (see <<< PROBLEM HERE) and the try/except block falls through to returnTrue
, which allows the instance to start regardless of the exclusion lock.The problem line should simply return the result of
locks.lock
.The text was updated successfully, but these errors were encountered: