Repository navigation
perf: run the single-statement reads at AUTOCOMMIT - #64
Merged
Merged
Conversation
This was referenced Oct 17, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #63. Login,
GET /auth/me/,GET /chats/andGET /chats/{id}/each run one use case that sends a single SELECT. They now useDatabase.autocommit_transaction, as the revocation check already does, so the asyncpg adapter sends that SELECT without a BEGIN or a COMMIT. That saves 2 round trips per request.Round trips
Measured against a real engine on this branch with a scratch test (not committed). It counted every statement SQLAlchemy sent plus every
asyncpg.Connection.executecall, which is how the adapter sends BEGIN and COMMIT. Each request ran once to warm the statement cache before it was measured. Authenticated rows include the revocation check, which is already one round trip after #63.The message list stays in a normal transaction. It checks membership and then lists the page, and the two reads should see the same snapshot. Statement counts do not change, so
tests/api/test_statement_counts.pyis untouched.Changes
ioc.UseCases: the four providers getkwargs={"transaction": Database.autocommit_transaction}. Each query is still inside itsTransactionblock, so the recovery from ADR 0010 still applies.tests/use_cases/test_check_token_revoked.pyis nowtest_autocommit_reads.py. It runs each of the five autocommit use cases against a real engine and checks that asyncpg reports no open transaction while the query runs. The first commit adds the four new cases, and they fail on main.tests/use_cases/test_connection_loss.py: the four use cases move out of the lost-connection-in-session tests and stay in the pooled ones. The in-session fixture leaves the request session holding a connection before the use case starts, and SQLAlchemy then ignores the isolation option withSAWarning: Connection is already established for the given bind; execution_options ignored, whichfilterwarnings = errorturns into a failure. Production cannot reach that state for these use cases. Each endpoint runs one use case on a fresh request session, andTransaction.__aexit__closes the session beforepostgres_retrytries again. perf: cut avoidable SQL round trips from every endpoint #63 made the same call for the revocation check. The in-session tests still cover the message list, message send and mark-read.AGENTS.mdlists which use cases take the autocommit transaction and why multi-statement reads do not.Testing
just test: 154 passed, coverage 100%.just lintis clean.