surrealdb/surrealdb.py

Bug: Concurrency issues when using FastAPI

juangesino opened this issue · 3 comments

juangesino commented

Describe the bug

When trying to use SurrealDB in a FastAPI project, whenever I get concurrent requests that hit the database, the application raises the following exception:

RuntimeError: cannot call recv while another coroutine is already waiting for the next message

After that, the server becomes unresponsive and the only solution is to restart.

Steps to reproduce

Assuming you have docker installed:

  1. Clone this repository: git clone https://github.com/juangesino/surrealdb-fastapi-concurrency-error
  2. Go to the repository source: cd surrealdb-fastapi-concurrency-error
  3. Build and start the docker containers: make build or docker-compose -f docker-compose.yml up --build --force-recreate
  4. Run the sequential test (this one should work fine): make sequential or docker exec -it surreal-demo-server-1 python demo_sequential.py
  5. Run the concurrent test (this one will fail): make concurrent or docker exec -it surreal-demo-server-1 python demo_concurrent.py

You should get the exception mentioned before:

RuntimeError: cannot call recv while another coroutine is already waiting for the next message

The server will not respond after that and you will have to restart it.

Expected behaviour

The Python SDK should be able to handle concurrent requests.

SurrealDB version

surrealdb/surrealdb:v1.5.0 (docker)

surrealdb.py version

0.3.2 for python:3.11.4-slim-buster (docker)

Contact Details

https://discord.com/channels/902568124350599239/1245739617525960778/1245768819553603666

Is there an existing issue for this?

  • I have searched the existing issues

Code of Conduct

  • I agree to follow this project's Code of Conduct
MarcusVirg commented

I have the same issue when using FastAPI. I am also seeing an issue where a request to the database actually returns a previous query result causing serialization issues with my project. I haven't been able to recreate consistently but I imagine this is an issue related to socket polling happening out of order. It really makes this library unusable in production APIs at the moment.

shkr commented

Same issue

krikkiteer commented

same issue.. when using within litestar, or plain python-service.