Use APScheduler version 4.0.0a3, It is not possible to run the examples/web/asgi_fastapi.py file repeatedly.

pangxiaobin commented 8 months ago

Things to check first

[X] I have checked that my issue does not already have a solution in the FAQ
[X] I have searched the existing issues and didn't find my bug already reported there
[X] I have checked that my bug is still present in the latest release

Version

APScheduler==4.0.0a3

What happened?

When executing the demo examples/web/asgi_fastapi.py, I encounter an issue where it fails to run for the second time. On each subsequent run, I am required to delete the tables from the database before proceeding.

The initial run proceeds without errors, but upon subsequent executions, an error is encountered. First-time execution log:

INFO:     Started server process [47192]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://127.0.0.1:8080 (Press CTRL+C to quit)
Hello, the time is 2023-11-02 16:40:46.106430
Hello, the time is 2023-11-02 16:40:47.034011
Hello, the time is 2023-11-02 16:40:47.897712
Hello, the time is 2023-11-02 16:40:48.890239
Hello, the time is 2023-11-02 16:40:49.884938
Hello, the time is 2023-11-02 16:40:50.897830
INFO:     Shutting down
INFO:     Waiting for application shutdown.
INFO:     Application shutdown complete.
INFO:     Finished server process [47192]
INFO:     ASGI 'lifespan' protocol appears unsupported.

Subsequent execution log:

INFO:     Started server process [45848]
INFO:     Waiting for application startup.

Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)

No specific error message is being provided.

It appears that there is no validation being performed for existing database tables.

How can we reproduce the bug?

use examples/web/asgi_fastapi.py code.

agronholm commented 8 months ago

The ASGI 'lifespan' protocol appears unsupported. error actually masks some exception. It's worth noting that APScheduler 4 requires AnyIO 4 which does not work yet with FastAPI.

That said, I tried with the latest master version and it seems to work fine. Could you try again with the latest alpha release?

pangxiaobin commented 7 months ago

The ASGI 'lifespan' protocol appears unsupported. error actually masks some exception. It's worth noting that APScheduler 4 requires AnyIO 4 which does not work yet with FastAPI.

That said, I tried with the latest master version and it seems to work fine. Could you try again with the latest alpha release?

Thank you for your response. I have conducted some tests and have determined that the issue lies in the conflict of creating database tables. Upon reviewing your source code, I have found that setting the following parameter should resolve the error that occurs upon subsequent runs:

engine = create_async_engine("postgresql+asyncpg://postgres:password@localhost/testdb")
data_store = SQLAlchemyDataStore(engine)
data_store.start_from_scratch = True

pangxiaobin commented 7 months ago

The ASGI 'lifespan' protocol appears unsupported. error actually masks some exception. It's worth noting that APScheduler 4 requires AnyIO 4 which does not work yet with FastAPI. That said, I tried with the latest master version and it seems to work fine. Could you try again with the latest alpha release?

Thank you for your response. I have conducted some tests and have determined that the issue lies in the conflict of creating database tables. Upon reviewing your source code, I have found that setting the following parameter should resolve the error that occurs upon subsequent runs:
engine = create_async_engine("postgresql+asyncpg://postgres:password@localhost/testdb")
data_store = SQLAlchemyDataStore(engine)
data_store.start_from_scratch = True

I apologize for any confusion caused. It seems that my previous understanding was incorrect. Upon further consideration, I believe I have identified the true cause of the error. It appears that when adding events, the duplication of IDs upon subsequent runs is leading to the failure of database insertion.

 await self.scheduler.add_schedule(
                    tick, IntervalTrigger(seconds=1), id="tick"
                )

agronholm commented 7 months ago

It appears that when adding events, the duplication of IDs upon subsequent runs is leading to the failure of database insertion.

No, the scheduler just updates the schedule in such cases, and does not try to insert a duplicate schedule. Otherwise I would be seeing errors too on subsequent runs. Are you seeing issues on the latest alpha?

pangxiaobin commented 6 months ago

I have tested it again, using both the latest version and the old version, and the previous issue did not reoccur. You can go ahead and close this issue. Thanks again for your response and the effort put into the project.

agronholm / apscheduler