payjoin
WIP:Demonstrate failure handling with fallback TX broadcast
As a refrence implementation , payjoin-cli needs to demonstrate proper fallback transaction handling in the case of payjon failure. From what i see , both sender and receiver can broadcast the fall back transaction , This pr starts by handling the sender side of things and would eventually progress to the receiver .
This is still a work in progress
this addresses #1156 .
- [x] handle v1 sender broadcasting fallback
- [x] handle v2 sender broadcasting fallback
- [ ] handle v2 receiver broadcasting fallback
- [ ] check that transaction is broadcastable before broadasting
Pull Request Checklist
Please confirm the following before requesting review:
- [x] I have disclosed my use of AI in the body of this PR.
- [x] I have read CONTRIBUTING.md and rebased my branch to produce hygienic commits.
Pull Request Test Coverage Report for Build 19315152668
Details
- 14 of 55 (25.45%) changed or added relevant lines in 1 file are covered.
- 2 unchanged lines in 1 file lost coverage.
- Overall coverage decreased (-0.2%) to 83.335%
| Changes Missing Coverage | Covered Lines | Changed/Added Lines | % |
|---|---|---|---|
| payjoin-cli/src/app/v2/mod.rs | 14 | 55 | 25.45% |
| <!-- | Total: | 14 | 55 |
| Files with Coverage Reduction | New Missed Lines | % |
|---|---|---|
| payjoin-cli/src/app/v2/mod.rs | 2 | 50.73% |
| <!-- | Total: | 2 |
| Totals | |
|---|---|
| Change from base Build 18946545260: | -0.2% |
| Covered Lines: | 8991 |
| Relevant Lines: | 10789 |
💛 - Coveralls
@arminsabouri i implemented error downcast method for v2 in this PR, the downside of this method is having to repeat the same block of code for the the different state of the senders session. I only did it for the "pooling proposal" phase of the sender session, i'll have to do it for the rest of the phases but just want to know your input on this before i head that direction.
i'm also simutaneously working on the "session outcome" based solution with the draft PR from you .