fix: prevent asyncio.Lock deadlock in AsyncTxn.do_request error handling

[shaunpatterson]

Summary

Fixes a deadlock in the async client when an error occurs during do_request().

Root Cause: When an error occurs in do_request(), the code calls self.discard() while still holding self._lock. Since discard() also tries to acquire self._lock and asyncio.Lock is not reentrant, this causes a deadlock.

The deadlock scenario:

1. do_request() acquires self._lock (line 171)
2. A gRPC error occurs (e.g., schema error, missing index)
3. Error handler calls await self.discard() (line 221)
4. discard() tries to acquire self._lock (line 460)
5. DEADLOCK - the lock is already held by do_request()

Fix

• Extract discard logic into _discard_internal() which doesn't acquire the lock
• Update do_request() error handler to call _discard_internal() directly
• Update public discard() to acquire lock then delegate to _discard_internal()
• Add defensive assertion to verify lock is held when calling internal method

Testing

Tested by reproducing the deadlock scenario:

• Query with variables against a predicate without an index triggers a schema error
• Error handler previously deadlocked; now properly discards and raises the error

Validation

This fix was reviewed by GPT-5 and Gemini 2.5 Pro, both confirmed:

1. The fix correctly addresses the asyncio.Lock deadlock
2. No new race conditions are introduced
3. The naming convention (_discard_internal) is idiomatic Python
4. The defensive assertion is good practice

---

Generated with Claude Code

[mlwelles]

Good catch. I opened a new PR (#296) with the changes needed for us to be able to approve and merge:

• Added tests that reproduce the bug and validate the fix.
• Removed the use assert() outside of a test and replaced with an explicit check and exception raise. The pre-commit checks flagged this one -- Python simply skips over any assertions it encounters when running optimized mode (running with the -O flag), which can lead to unanticipated consequences.

Going to close this PR in favor of the other, and we'll cut a new patch release that includes the fix ASAP.

Thanks!