Repository navigation
fix: the prepared statement lifecycle - free once, refused after - #492
Merged
Merged
Conversation
Each execution of a prepared statement is submitted ... done, with no free; free is raised once, by ps.free(), when the native statement is released. After that, any use is an error. - native (bind_fetch): each execution clears the last one's diagnostics and closes the cursor it left open. after an execution failed part way, the next failed with 24000 and reported the old error again - an execution after free() is refused with HY010 (the error or callback, then done), with no native call; it ran on the released handle before, with two callbacks and a garbled message - a second free() is refused in its callback; it threw and left the connection unable to close - free() asked for while an execution runs waits for its done Corpus: scripts/prepared (agreed), with t.watch / t.next script helpers. Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
… diagnostics A current state at the top (the four issues, what guards them, the corpus status, what is left before v6), the contract as it now stands in full, and a Next plan led by never dropping what the driver sends (a new info/ corpus group first). The older sections are marked as history. Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
The cancel callback and the HY008 from the fetch in flight are two native completions on different threads; CI saw the other order. Both meet the contract, so the transcript lists both (--- or). Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
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.
Contract:
submitted…done, with nofree.freeis raised once, byps.free(), when the native statement is released.What was wrong, recorded in the new
scripts/prepared(agreed):free.bind_fetch): each execution clears the last one's diagnostics and closes any cursor left open.free()ran natively on the released handle. It got two callbacks: the garbled "prepared statement has been Debugd", then "Invalid statement handle".done, with no native call.free()threw "Invalid statement handle", and the connection could no longer close.free()while an execution runs waits for it: the execution'sdone, thenfree.Corpus tooling: new script helpers
t.watch(label, q), which logs a query object made some other way, andt.next(label, event). Prepared executions share one query object and never free, sot.querydoes not fit them.Found, not fixed (in HANDOVER): a prepared select with no table behind it (
select 10 / ? as n) is described with no columns, so its executions return no rows.Seen once, not reproduced:
cancel/again-after-confirm-at-100failed once in about 50 local runs, and the transcript was not kept. If CI shows it, the failure prints the variant.Local (Windows): full suite 1075 passing, replay 150 passing.
🤖 Generated with Claude Code