Open litagent opened 7 months ago
+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.
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.
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.
@RobertCraigie I see this in a Postgres (Supabase), FastAPI, one global prisma
setup, but I'm not sure what triggers it.
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