DanGould / rust-payjoin / 25513952263

85%

master: 85%

push

github

Add v2 receiver fallback subcommand

Mirror the sender-side fallback that shipped in PR #1510. The
existing `Fallback { session_id }` subcommand now dispatches to
either sender or receiver flow based on which DB table the
session_id belongs to: sender table first (existing behavior
preserved), then receiver table, else error.

The library gains `Receiver<S: State>::broadcast_fallback()`, a
terminal transition that mirrors `Receiver::cancel()` but records
`SessionOutcome::FallbackBroadcasted` instead of `Cancel`,
returning the fallback transaction so the caller can broadcast it.

The `App` trait gains `fallback(session_id)` as the unified entry
point. `fallback_sender` and `fallback_receiver` stay as separate
trait methods for direct invocation; `fallback` is the dispatcher
that consults the new `Database::has_send_session` and
`Database::has_recv_session` lookups before routing. v1 implements
all three trait methods as bail-outs with the same wording.

The v2 `fallback_receiver` implementation replays the receiver
event log; if the session is closed-success or already-broadcast
it no-ops with an explanatory message, otherwise it broadcasts
`SessionHistory::fallback_tx()` via the wallet, saves the
`Closed(FallbackBroadcasted)` event, and closes the session.

The new `receiver_fallback_v2` e2e test in payjoin-cli mirrors
`sender_fallback_v2`: drive a v2 receiver past the broadcast
suitability check via SIGKILL of the resume process, then invoke
`fallback` against the receiver DB and assert the original lands
in the regtest mempool.

Receivers want a way to recover funds when a v2 payjoin session
gets stuck after the sender has posted but before the receiver can
finalize and post a proposal. Without this command, operators have
no programmatic path from a stuck session to a broadcast original.

21 of 36 new or added lines in 5 files covered. (58.33%)

11536 of 13561 relevant lines covered (85.07%)

403.77 hits per line