+1 on this - we're seeing this too

On my side this is clearly happening when handling multiple queries in parallel.

For me, this happens in two different scenarios.

• When handling multiple requests (my framework FastAPI, like any, will deal with them in parallel)
• When I gather multiple queries using asyncio.gather

I am used to having only one global Prisma client, I think it's best practice, and thus I could solve this by implementing a rudimentary lock mechanism (lock, queue and callbacks).

Yet I am not satisfied and expected this kind of stuff to be handled natively, but the doc is quite brief so I might have missed stuff. Anyone has a workaround or optim using the codebase (like .batch_)?

In the end what worked best for me was to perform requests sequentially using a queue management system.

Test error

To reproduce the error you can write an async test of the form:

@pytest.mark.asyncio
async def test_get_all_big(self):
    promises = [database.get_styles() for _ in range(100)]
    await asyncio.gather(*promises)

@Xmaster6y what database are you using? I can't replicate the issue with the snippet you shared running against PostgreSQL.

An hosted instance of SQL Server. I can't say if it's due to SQL Server but I've never seen this using directly prisma in js.

Also this passes (without my workaround):

@pytest.mark.asyncio
async def test_get_all_big_sync(self):
    results = [await database.get_styles() for _ in range(10)]
    assert len(results) == 10

I also experienced this error.

I guess it happens when the client received data which is bigger than it could handle(i.e. out of memory).
I tested with a table that has a huge JSON column and it raises an error.

related to issue: encode/httpx#1171 (comment)

@RobertCraigie I see this in a Postgres (Supabase), FastAPI, one global prisma setup, but I'm not sure what triggers it.

^ Having this issue as well when doing a lot of async calls simultaneously.

Related discussion/comment.

Probably needs minor adjustments here. (I'm not acquainted with this codebase so good chance I'm wrong)

I confirm that changing the request method as the following solves my issue (without my workaround):

    @override
    async def request(self, method: Method, url: str, **kwargs: Any) -> 'Response':
        async with httpx.AsyncClient(**self.session_kwargs) as session:
            return Response(await session.request(method, url, **kwargs))

Couple notes:

• I couldn't reproduce the issue either with sqlite (expected) or postgresql
• The (db) tests are approximately 3 times slower (with postreges ~10s -> ~30s), likely this fix is a bit overkill but I am not so familiar with the codebase either
• I can work on a config to run the db tests on a SQL Server

Thanks @Xmaster6y, what version of httpx / httpcore have you been testing with? I know some of the more recent versions have fixed some connection leaking issues.

@RobertCraigie I used to have httpx 0.27.0 but even 0.27.2 (latest) raised the issue.

EDIT

The error mentionned bellow only happens when the test is runned individually (in VSCode) not when runned grouped. So it might be a fixture issue or else.

Other Error

My fix seems to suffer from a new (really weird problem). Whenever 1<X<30 the code fails but when X=1 or X>29 it works fine (even X=1000):

    @pytest.mark.asyncio
    async def test_get_all_big(self):
        promises = [database.get_styles() for _ in range(X)]
        await asyncio.gather(*promises)

+1 on this - we're seeing this too

@ishaan-jaff did litellm fix this bug? I encountered this error. version: litellm-non_root:main-v1.48.17-stable

I'm facing the same issue

• OS: Ubuntu
• DB: Postgres
• Python: 3.10
• Framework: FastAPI

I'm working with nicegui (webapps development) which relies at FastAPI.

When the server starts to run, tries to render the root page which performs a find_many query to provide a search bar with data.

Sometimes the error comes up sometimes doesn't (and almost every time using the hot reload feature during developing).

The solution to my case isn't a fix at all, it only tries to give some context.
So, relocate the find_many query behind a function which triggers upon an event made the trick.
By the moment I'm facing the issue on start up and/or on reload.

On the other side, when I face the issue starting/reloading the app, if the page is refreshed, the query will work fine.
Probably this is related with the fact that FastAPI tries to render the root page at the same time that the find_many query is performed.

I've opened other issue at nicegui repo with a minimal example
I hope this can help