Return error on duplicate input contribution

[Mshehu5]

This is a followup to #1254 to address #1254 (comment)

I fear this test is a silent error. Shouldn't contributing duplicate inputs cause error rather than continue and produce the same result with differing input?

Previously, contribute_inputs() filtered out duplicate inputs when the same outpoint was provided multiple times.
This PR makes it cause an error

Pull Request Checklist

Please confirm the following before requesting review:

• I have disclosed my use of
  AI
  in the body of this PR.
• I have read CONTRIBUTING.md and rebased my branch to produce hygienic commits.

[coveralls]

Pull Request Test Coverage Report for Build 20795200310

Details

• 14 of 17 (82.35%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.001%) to 82.908%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
payjoin/src/core/receive/error.rs	0	3	0.0%

Totals
Change from base Build 20717534858:	-0.001%
Covered Lines:	9682
Relevant Lines:	11678

---

💛 - Coveralls

[DanGould]

May I understand your rationale between the two? My question was genuine. It wasn't an instruction in disguise.

[DanGould]

Looks like a reasonable approach. Please consider the comment formatting to regular complete sentences.

[Mshehu5]

May I understand your rationale between the two? My question was genuine. It wasn't an instruction in disguise.

While working on #1254 based on the discussion by other contributors, it was noted in the issue that:

Maybe it should filter for unique new inputs.

After implementing the filtering I also considered that erroring out might be a better approach. However I didn’t add this because it wasn’t mentioned in the issue and I was unclear whether erroring on duplicate inputs was the intended flow for contribute_inputs.

Based on payjoin-cli this function is mostly used only once so I assumed duplicate inputs might be handled gracefully (by filtering) rather than causing an error. Additionallyz if the inputs are insufficient or intentionally filled with duplicates the logic would still result in a ValueTooLow error if the total amount does not meet the required threshold.

These were some of the considerations behind my approach. The reason I submitted a minimal filtering PR was that if erroring out is the preferred behavior it would likely be flagged by other contributors (as you’ve done) which is why I proceeded with a follow-up PR.

Incase of next time I think is best I ask more questions in the issue or add notes for reviewers to consider in the PR to better address the issue