Repository navigation
fix(connection): keep the UDF close() error when the UDF runs on the query thread - #71
Merged
Merged
Conversation
…query thread close() called from a UDF while its connection runs a query raised "close() cannot be called from a call on the same connection" instead of the UDF message whenever the UDF ran on the thread that issued the query: that thread's stack holds the connection's own call below the UDF marker. A constant argument folded while binding already runs the UDF there, and an engine that runs a one-thread task on the calling thread does so for every such task. The same-thread check now uses the UDF message when a UDF was entered after the connection's call, as the worker path does. The new close_from_a_folded_udf scenario covers it with RETURN closer(1). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
adsharma
self-requested a review
October 22, 2026 20:10
adsharma
requested changes
Oct 22, 2026
adsharma
left a comment
Contributor
There was a problem hiding this comment.
CI still failing against a fresh main repo build
…lure The C-API backend cannot register UDFs yet, so close_from_a_folded_udf stops at create_function() with NotImplementedError, like close_from_a_udf already listed here. The C-API job never reached pytest on this branch before, because its JSON extension smoke step crashed on the ladybug main build of the time. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
Author
|
The failure was in my new test. Running the C-API job locally against 319bb92, I also hit a flaky failure that |
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
2 participants
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.
This work was produced with the help of language models.
close()called from a UDF while its connection runs a query should raise "close() cannot be called from a UDF while the connection runs a query." It raises "close() cannot be called from a call on the same connection." instead whenever the UDF runs on the thread that issued the query: that thread's stack then holds the connection's own call below the UDF marker, andclose()checks for the call first. Onmainthis already happens when a constant argument is folded while binding (RETURN closer(1)). With LadybugDB/ladybug#1297, which runs a one-thread task on the calling thread, it also happens for a UDF over rows, andtest_close_with_query_in_flight[close_from_a_udf]fails. A UDF on an engine worker thread is unaffected. The close is refused either way; only the message is wrong.Fix. The same-thread check uses the UDF message when a UDF was entered after the connection's call (
_called_from_udf), as the worker-thread path already does.Tests. A new
close_from_a_folded_udfscenario runsRETURN closer(1)with a UDF that closes its connection; it fails onmainwithout the fix. The C-API backend cannot register UDFs yet, so the scenario is listed incapi_xfails.pynext toclose_from_a_udf. With the fix,test_connection_close.pypasses on pybind against ladybugmainand against LadybugDB/ladybug#1297, and the rest of the suite (without the torch-geometric and JSON-extension tests) gives the same results against LadybugDB/ladybug#1297 as againstmain.