Repository navigation
fix(jdbc): rotate the baton before checking endTransaction errors (#98) - #122
Merged
Merged
Conversation
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.
Fixes #98
Contract
Hrana 3 is the source of truth for transport, values, and metadata.
java.sqlis the source of truth for the JDBC surface. xerial/sqlite-jdbc is a behavioral reference and conformance foundation, never a copy target.Protocol basis. Hrana over HTTP
PipelineRespBodycarries a freshbatonin every response, including a response whoseresultscontain aStreamResultError. The client must consume that baton before inspecting the results.Change
LibsqlConnection.endTransactionnow callsupdateStreamState(resp)immediately after the pipeline returns, before any result inspection, matchingbeginTransactionandexecuteStatement. The two ad hoc baton assignments in the re-begin error branches are gone because the state is already current there.LibsqlConnectionTest's scripted client now issues a fresh baton per response and throws on a reused baton, so it behaves like sqld. The new case fails a COMMIT, rolls back, and runs another statement.TransactionLifecycleITreplays the issue against real sqld with a deferred foreign key.Red evidence
Base
dea07fa, with the new tests applied and production code unchanged../mvnw -pl libsql-jdbc test -Dtest=LibsqlConnectionTest: 13 run, 3 errors, eachstale baton baton-2raised by the scripted client fromendTransaction. Log/tmp/xerial-parity-i98/lane-1-trunk.log../mvnw -pl libsql-itests -am verify -Dit.test=TransactionLifecycleIT:failedCommitCanBeRolledBackAndTheConnectionStaysUsableerrors atrollback()withSQL HTTP error 400: Received a baton that has already been used. Log/tmp/xerial-parity-i98/lane-2-trunk.log.Green evidence at head 7c9d889
LibsqlConnectionTest: 13/13,BUILD SUCCESS.libsql-jdbcsuite: 190/190.TransactionLifecycleIT4/4, including the failed COMMIT then ROLLBACK case.BUILD SUCCESS, 115 run, 1 skipped.BUILD SUCCESS, 100 run, 1 skipped.spotless:check: no violations../mvnw test:BUILD SUCCESS.package -DskipTests: the driver jar builds../mvnw -pl libsql-jdbc test, 3 runs per side interleaved. Trunk median 2089 ms, head median 2083 ms.Divergence
None in behavior. The baton rotation rule has no xerial analog because the reference driver is in-process, so there is no reference note beyond this protocol obligation.
Base
dea07fa, head7c9d889.