place_bet and request_withdrawal released everything on any exception from the
broadcast, including the 15s timeout and a connection dropped after the write. The
tx may have propagated: a bet's sats landed in the pool with no participant, a
withdrawal left while its row said failed and its coins were spendable again.
- client: ElectrumRpcError (subclass of ElectrumError) is raised only for a reply
carrying a JSON-RPC `error`; timeouts, drops and write errors stay plain
ElectrumError.
- tx/outcome.py:broadcast_with_verdict sorts a broadcast into accepted / refused /
uncertain. A refusal is verified first: ElectrumListener.transaction_known asks
blockchain.transaction.get of the active server and every other one (10s each) —
any server returning the tx means accepted; the active server plus
MIN_QUORUM_RESPONSES others all denying it means refused (ALLOW_NO_QUORUM keeps
the reduced rule); too few answers is uncertain. "already known" wording is only a
shortcut that skips the check. With no network to ask, a refusal is uncertain.
- place_bet / request_withdrawal / _trigger_payout use it: only a verified refusal
releases; uncertain leaves the rows building for the reconciler, publishes SSE and
POST /bets and POST /withdrawals answer 202 with status building; "already known"
promotes a payout (payout_sent) like any accepted broadcast.
- An accepted transaction is fanned out to every other server
(ElectrumListener.fan_out_transaction, best effort, off the caller's path). The RBF
replacement in bump_fee is left for B-77, which rewrites that function.
Tests changed because the spec changed: the existing "refused broadcast" tests raised
a bare RuntimeError (now an uncertain outcome) and are made explicit refusals
(rpc_error) with a network that denies the tx; direct route calls pass a Response;
FakePayoutListener gains the network surface.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
pysqlite's legacy mode emitted BEGIN only at the first DML, so every read
before it ran outside any transaction and a lock wait surfaced as "database is
locked" at an arbitrary later statement; place_bet also mistook that error for
a write-snapshot conflict, which SQLite cannot produce.
- _register_sqlite_pragmas: synchronous=FULL, isolation_level=None and a
`begin` event that emits BEGIN / BEGIN IMMEDIATE.
- begin_immediate(session): takes the write lock before the first read; called
first thing in place_bet, request_withdrawal, the scheduler transitions,
_trigger_payout, the confirmation poller, the reconciler, bump_fee's persist
phase, deposit crediting / external-spend marking / reinstating, and the
derivation-index allocation at registration.
- A lock not granted before a broadcast answers service_busy (503, all seven
languages), nothing built or sent; after a broadcast nothing is undone, the
rows stay `building` for the reconciler.
- Spec, storico, BUGS.md and CLAUDE.md updated; 37 new tests on a real file DB.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>