RuntimeError: cannot schedule new futures after interpreter shutdown

[BRGustavo]

Things to check first

• I have checked that my issue does not already have a solution in the FAQ

• I have searched the existing issues and didn't find my bug already reported there

• I have checked that my bug is still present in the latest release

Version

3.10.4

What happened?

Hello,

I'm trying to create a Python code orchestrator that schedules a function to be called 20 seconds after being triggered. However, every time it runs, the log shows a RuntimeError stating that new tasks cannot be scheduled after the interpreter has shut down.

Interestingly, I used this same code with Python 3.7 without any issues. The only change I've made is updating Python to version 3.10 and APScheduler to version 3.10.4.

Here is the error log:

[INFO] 2024-11-09 20:02:49,514 - apscheduler.scheduler - Removed job frontend_305_
[INFO] 2024-11-09 20:03:41,713 - apscheduler.scheduler - Scheduler started
[INFO] 2024-11-09 20:03:55,294 - apscheduler.scheduler - Added job "QueeList.execute_process" to job store "default"
[ERROR] 2024-11-09 20:04:15,297 - apscheduler.scheduler - Error submitting job "QueeList.execute_process (trigger: date[2024-11-09 20:04:15 -03], next run at: 2024-11-09 20:04:15 -03)" to executor "default"
Traceback (most recent call last):
  File "C:\Users\gusta\teste\Em andamento\PyControlAPI\backend\nvenv\lib\site-packages\apscheduler\schedulers\base.py", line 988, in _process_jobs
    executor.submit_job(job, run_times)
  File "C:\Users\gusta\teste\Em andamento\PyControlAPI\backend\nvenv\lib\site-packages\apscheduler\executors\base.py", line 71, in submit_job
    self._do_submit_job(job, run_times)
  File "C:\Users\gusta\teste\Em andamento\PyControlAPI\backend\nvenv\lib\site-packages\apscheduler\executors\pool.py", line 28, in _do_submit_job
    f = self._pool.submit(run_job, job, job._jobstore_alias, run_times, self._logger.name)
  File "C:\Users\gusta\AppData\Local\Programs\Python\Python310\lib\concurrent\futures\thread.py", line 163, in submit
    raise RuntimeError('cannot schedule new futures after '
RuntimeError: cannot schedule new futures after interpreter shutdown

How can we reproduce the bug?

from logging import basicConfig,  INFO, FileHandler
from apscheduler.schedulers.blocking import BlockingScheduler
from apscheduler.triggers.cron import CronTrigger
from datetime import datetime, timedelta
from typing import Optional
import threading


class QueeList:
    def __init__(self, scheduler=None):
        self.scheduler = scheduler
    
    def execute_process(self, process_value):
        print("hello world!")
        
    def reload_proess_database(self):
        list_values = [("*/5 * * * *", "teste", 10, "teste")]
        for cron_value, process_value, process_id, process_name in list_values:
            self.scheduler.add_job(self.execute_process, trigger="date", run_date=datetime.now() + timedelta(seconds=20), args=[process_value], id=f"frontend_{process_id}_{process_name}")


def main_orchestrator_control(save_logs):
    scheduler = BlockingScheduler()
    list_process = QueeList(scheduler)
    list_process.reload_process_database()
    list_process.scheduler.start()

def control_start_orchestrator():
    try:        
        orchestrator = threading.Thread(target=main_orchestrator_control, name="OrchestratorController", args=(False), daemon=True)
        orchestrator.start()
        
    except Exception as erro:
        print("problema ao executar função.")


if __name__ == "__main__":
    VAR_PATH_LOGS_SYSTEM = "C:/temp/TesteOrchestrator.txt"
    VAR_MESSAGE_LOG_FORMAT = "[%(levelname)s] %(asctime)s - %(name)s - %(message)s"

    basicConfig(level=INFO, format=VAR_MESSAGE_LOG_FORMAT, handlers=[FileHandler(VAR_PATH_LOGS_SYSTEM, "a", "utf-8")])

    orchestrator = control_start_orchestrator() 

[fti-rgurav]

I’m encountering the same issue with APScheduler 3.10.4 in Python 3.11.10. The traceback is as follows:

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/apscheduler/schedulers/base.py", line 988, in _process_jobs
    executor.submit_job(job, run_times)
  File "/usr/local/lib/python3.11/site-packages/apscheduler/executors/base.py", line 71, in submit_job
    self._do_submit_job(job, run_times)
  File "/usr/local/lib/python3.11/site-packages/apscheduler/executors/pool.py", line 28, in _do_submit_job
    f = self._pool.submit(run_job, job, job._jobstore_alias, run_times, self._logger.name)
  File "/usr/local/lib/python3.11/concurrent/futures/thread.py", line 169, in submit
    raise RuntimeError('cannot schedule new futures after ')
RuntimeError: cannot schedule new futures after interpreter shutdown

Is there a workaround or fix available? I’d appreciate any guidance or suggestions.

[agronholm]

I’m encountering the same issue with APScheduler 3.10.4 in Python 3.11.10. The traceback is as follows:

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/apscheduler/schedulers/base.py", line 988, in _process_jobs
    executor.submit_job(job, run_times)
  File "/usr/local/lib/python3.11/site-packages/apscheduler/executors/base.py", line 71, in submit_job
    self._do_submit_job(job, run_times)
  File "/usr/local/lib/python3.11/site-packages/apscheduler/executors/pool.py", line 28, in _do_submit_job
    f = self._pool.submit(run_job, job, job._jobstore_alias, run_times, self._logger.name)
  File "/usr/local/lib/python3.11/concurrent/futures/thread.py", line 169, in submit
    raise RuntimeError('cannot schedule new futures after ')
RuntimeError: cannot schedule new futures after interpreter shutdown

Is there a workaround or fix available? I’d appreciate any guidance or suggestions.

How are you reproducing this issue? The code OP posted is wrong, as it uses a BlockingScheduler in a thread for some bizarre reason.

[agronholm]

@BRGustavo I cannot reproduce the problem with your script. Once I fixed the obvious bugs (the logging pointing to a nonexistent path and the args argument not being a tuple), I run the script and it exits immediately.

@fti-rgurav please provide further information.

Unless I get proof that there is an actual bug, I will close the issue. I won't spend a lot of time on a wild goose chase.