Closed v-v-d closed 3 months ago
Hi and thanks for reaching out with this very detailed report :smile:
This is, while maybe surprising, expected behavior. If you were to enable debug logging, you'd see that the driver will send the timeout to the server as you specified it. So it's the server's responsibility to enforce the transaction timeout. The driver doesn't process it any further. That being said, I remember being surprised by this behavior myself at some point and asked our DBMS kernel developers what's going on. (Implementation detail follows, i.e., this could change in the future) There is a watcher thread in the DBMS that checks every not and then:tm: (I think currently 2s) whether there are any transactions that have exceeded their configured timeout. If so, they will be terminated.
TL;DR: the timeout cannot be arbitrarily small and the server might cut transactions some slack before terminating them.
I'll close the issue as there is nothing to do here. But I'll forward this issue to team kernel so they know that at least 2 people were surprised by this behavior. Let's see if that leads to something. If you have further questions, please feel free to keep commenting.
Hi! Got it, thank you very much for the detailed response! What do you think, could the use of the asyncio.timeout context manager be dangerous? Is it possible that on the client side a transaction is interrupted due to asyncio.TimeoutError, but on the Neo4j side, it remains open, thus generating anomaly load on Neo4j?
Several thoughts:
Bug Report
First of all, I want to thank you for the amazing Neo4j driver for Python with full asyncio support. It's really very cool and performs wonderfully! Thank you!
Now to the point. While using the driver, I've noticed that if explicit transactions are used and a timeout argument is passed at their initialization, the driver does not always respect this timeout. This leads to transactions containing queries that run for minutes when a timeout of just a few seconds is specified.
I have prepared a simple pytest test that confirms the above. You can run it via
docker-compose up --build
neo4j_test.zipCould you please tell me if this is a bug or expected behavior? Or maybe I'm doing something wrong?
This is a snippet of the test:
and this is one of the outputs:
My Environment
Python Version: 3.11 (python3.11-slim docker image) Driver Version: 5.18.0 Neo4j Bolt driver for Python Server Version and Edition: 5.18.0 community (from neo4j:5.18.0-community docker image) Operating System: debian bookworm (from python3.11-slim docker image)