Repository navigation
Bindings: a user function that calls its own write transaction hangs (UniFFI, C) #886
Description
Found while reviewing #824 (read from code, not reproduced).
MiniGrafWriteTransaction::execute (UniFFI shim: minigraf-binding-template, -python, -java, -android, -swift) and MiniGrafTx::with (minigraf-c) hold a std::sync::Mutex around the transaction for the whole statement. If a user function registered on the database calls execute, commit or rollback on that same transaction from inside one of its statements, it locks that mutex again on the same thread: a deadlock (std's Mutex is not reentrant).
Calls into the database from such a function are already refused with INT-001 (core sets the reentry flag on the thread running an owned transaction's statement, #885). Only calls into the transaction object are affected.
minigraf-node already refuses this case: its slot uses try_lock, and a held slot on the single JS thread can only mean re-entry, so it returns INT-001.
Expected: the call fails with INT-001 (the query then fails with QRY-014), as Node does.
Possible fix: record the thread running the current statement in the binding's transaction object and refuse a call from that thread before locking. A plain try_lock is not enough in the UniFFI and C bindings, because a concurrent call from another thread must wait for the statement (D9 in the #824 design).
Repro sketch (UniFFI crate test): register a predicate holding an Arc<MiniGrafWriteTransaction> whose test calls tx.execute(...), then run tx.execute("(query [... [(that-pred ?v)]])").
Refs #824
Activity
docs: a user function calling its own transaction gets INT-001 (minig…
adityamukho commentedon Nov 12, 2026
Fixed on the bindings'
v3branches: binding-template#14, python#22, java#27, android#20, swift#21, c#19; docs minigraf-docs#97. A user function that callsexecute,commitorrollbackon the transaction whose statement runs it now gets INT-001; a call from another thread still waits.