• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

DanGould / rust-payjoin / 25513952263
85%
master: 85%

Build:
Build:
LAST BUILD BRANCH: receiver-fallback
DEFAULT BRANCH: master
Ran 07 May 2026 06:21PM UTC
Jobs 1
Files 63
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

06 May 2026 06:08PM UTC coverage: 85.067%. First build
25513952263

push

github

DanGould
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

Uncovered Changes

Lines Coverage ∆ File
6
90.96
payjoin/src/core/receive/v2/mod.rs
4
68.18
payjoin-cli/src/app/v1.rs
3
55.08
payjoin-cli/src/app/v2/mod.rs
2
85.43
payjoin-cli/src/db/v2.rs
Jobs
ID Job ID Ran Files Coverage
1 25513952263.1 07 May 2026 06:21PM UTC 63
85.07
GitHub Action Run
Source Files on build 25513952263
  • Tree
  • List 63
  • Changed 0
  • Source Changed 0
  • Coverage Changed 0
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #25513952263
  • b12084b5 on github
  • Next Build on receiver-fallback (#25547534759)
  • Delete
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc