httpx.ConnectError: All connection attempts failed

[litagent]

Bug description

This issue "httpx.ConnectError: All connection attempts failed", is occurring rarely, can't replicate it. Do not why this issue is coming.

How to reproduce

Expected behavior

Prisma information

Environment & setup

• OS: debian
• Database: postgreSQL
• Python version: 3.11
• Prisma version: 0.9.1

[ishaan-jaff]

+1 on this - we're seeing this too

[Xmaster6y]

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_)?

[Xmaster6y]

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)

[RobertCraigie]

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

[Xmaster6y]

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

[lxxonx]

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.

[WesleyYue]

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