Taskiq version
0.12.4
Python version
Python 3.12
OS
Linux
What happened?
Description
The documentation describes --hardkill-count as the number of termination signals allowed before performing a hardkill.
However, the counter is currently implemented as:
hardkill_counter=0definterrupt_handler(signum, _frame):
nonlocalhardkill_countershutdown_event.set()
ifhardkill_counter>args.hardkill_count:
logger.warning("Hard kill. Exiting.")
raiseKeyboardInterrupthardkill_counter+=1Because the comparison happens before incrementing and uses >, --hardkill-count 3 behaves as follows:
| Signal | Counter before signal | Result |
|---|
| 1 | 0 | Graceful shutdown |
| 2 | 1 | Graceful shutdown |
| 3 | 2 | Graceful shutdown |
| 4 | 3 | Graceful shutdown |
| 5 | 4 | Hardkill |
If the value means “three termination signals before hardkill,” I would expect the fourth signal to trigger the hardkill. The current implementation triggers it on the fifth signal.
Would this condition be expected to use >= instead?
ifhardkill_counter>=args.hardkill_count:
logger.warning("Hard kill. Exiting.")
raiseKeyboardInterrupt
Taskiq version
0.12.4
Python version
Python 3.12
OS
Linux
What happened?
Description
The documentation describes
--hardkill-countas the number of termination signals allowed before performing a hardkill.However, the counter is currently implemented as:
Because the comparison happens before incrementing and uses
>,--hardkill-count 3behaves as follows:If the value means “three termination signals before hardkill,” I would expect the fourth signal to trigger the hardkill. The current implementation triggers it on the fifth signal.
Would this condition be expected to use
>=instead?