Skip to content

Bump payjoin version to 1.2.0 - #1929

Closed
benalleng wants to merge 2 commits into
payjoin:masterfrom
benalleng:bump-payjoin-1-2-0
Closed

benalleng wants to merge 2 commits into
payjoin:masterfrom
benalleng:bump-payjoin-1-2-0

Conversation

@benalleng

Copy link
Copy Markdown
Collaborator

This is a minor release as it adds the non-blocking interface and the related methods that can now be used instead of synchronous callbacks. This all keeps the existing methods so it remains backwards compatible.

GLM-5.3 helped me generate the changelog text.

Pull Request Checklist

Please confirm the following before requesting review:

@coveralls

coveralls commented Sep 29, 2026 •

Copy link
Copy Markdown
Collaborator

Coverage Report for CI Build 36739672490

Coverage remained the same at 87.074%

Details

  • Coverage remained the same as the base build.
  • Patch coverage: No coverable lines changed in this PR.
  • No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.


Coverage Stats

Coverage Status
Relevant Lines: 17353
Covered Lines: 15110
Line Coverage: 87.07%
Coverage Strength: 327.86 hits per line

💛 - Coveralls

DanGould
DanGould previously approved these changes Sep 30, 2026

@DanGould DanGould left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK 5b6aac2

Kind of verbose and I think somewhat incorrect changelog. Also, this PR could be a stack to make merging easier.

master
 └─ bump payjoin 1.2.0            (#1929)
     └─ bump payjoin-mailroom
         └─ bump payjoin-test-utils
             └─ bump payjoin-ffi / payjoin-cli

that released all this stuff at once so we don't run into the same problem again.

Comment thread payjoin/CHANGELOG.md
Comment on lines +42 to +52
### Bug Fixes

- Reject proposals that drop or reorder the sender's original inputs
before classifying any input as sender or receiver contributed. Input
classification treated any proposed input whose outpoint did not match
an original one as receiver-contributed, so a receiver that altered a
sender outpoint was validated as though the receiver had contributed
it, and the sender only learned something was wrong from a later
finalization error that pointed at the wrong thing. Dropped and
reordered inputs are now both rejected up front with
`MissingOrShuffledInputs` (#1836)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this was actually a bug fix, just a misleading commit log that led to this. This was a test adjustment

@benalleng benalleng Sep 30, 2026 •

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't is_ordered_subsequence() in 283663e actually cover a real issue?

@benalleng

Copy link
Copy Markdown
Collaborator Author

Also, this PR could be a stack to make merging easier.

To make a stack it would all need to come from my master branch at once. let me try to see what that looks like

@DanGould

Copy link
Copy Markdown
Member

I think you can push a bunch of different branches to this repository and stack them, no?

@benalleng

Copy link
Copy Markdown
Collaborator Author

Will do, just practicing on my fork now

This is a minor release as it adds the non-blocking interface and the
related methods that can now be used instead of synchronous callbacks.
This all keeps the existing methods so it remains backwards compatible.
@benalleng

Copy link
Copy Markdown
Collaborator Author

Closed as replaced by #1931

@benalleng benalleng closed this Sep 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants