Repository navigation
[Regression on closed #318] milestones::contribute's existing-sponsor lookup still calls unwrap() on Contribution records #418
Description
Activity
- addedbugSomething isn't workingSomething isn't workingsecuritySecurity-related issueSecurity-related issueStellar WaveIssues in the Stellar wave programIssues in the Stellar wave program
on Sep 27, 2026 @Wittig18 has applied to work on this issue as part of the Stellar Wave Program's 9th wave.
hey maintainer, i would love to work on this
ℹ️ Repo Maintainers: To accept this application, review their application or assign @Wittig18 to this issue.
nasirudeenbadirudeen87-cloud commented
on Sep 27, 2026 More actions@nasirudeenbadirudeen87-cloud has applied to work on this issue as part of the Stellar Wave Program's 9th wave.
Hi maintainer, I'd very much appreciate the opportunity to work on this issue.
Having reviewed the acceptance criteria, I'm confident that I'd be able to have a PR up shortly after being assigned.
Kindly assign this issue to me.
Thank you!ℹ️ Repo Maintainers: To accept this application, review their application or assign @nasirudeenbadirudeen87-cloud to this issue.
edehvictor commented
on Sep 27, 2026 ContributorMore actions@edehvictor has applied to work on this issue as part of the Stellar Wave Program's 9th wave.
I’d love to help out with this issue. I’ve checked the current codebase/documentation and know exactly what needs to be updated to make this clearer. I will ensure everything aligns perfectly with your existing contribution guidelines.
ℹ️ Repo Maintainers: To accept this application, review their application or assign @edehvictor to this issue.
Congratulations, @edehvictor! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on September 30, 2026.
🧑💻 @edehvictor: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.
Warning
When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.
🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.
🌊 Happy Wave 🌊
grantfox-oss commented
on Sep 28, 2026 grantfox-ossboton Sep 28, 2026 – with GrantFox OSSMore actions🎉 This issue has been marked as completed on GrantFox!
@edehvictor's PR #422 was approved and merged by @chonilius.
🏆 @edehvictor: You earned 40 FoxPoints for this contribution! Your current tier: Builder (1,602 total points). Track your full progress on GrantFox.
👏 Great work, @edehvictor! Keep contributing to MergeFi.
This issue has been completed by @edehvictor as part of the Stellar Wave Program's 9th Wave 🥳
😎 @edehvictor: You earned 200 Points for completing this issue! After the current Wave ends, you'll be eligible for a percentage of the Wave's reward pool based on the percentage of total points you've earned. Learn more here. You can also Leave a review to share your experience working on this issue.
🧑💻 Repo maintainers: How'd the contributor do? Leave a review to share your experience working with them.
Problem
#318 reported the same unwrap-on-archived-record panic risk as #317, in
milestones::contribute. It's closed as completed, butcontracts/milestones/src/lib.rsonmainstill has two.unwrap()calls, at about lines 210 and 238:refund_remaining_budgetin the same file (#103) already returns a typed error for a missing record, socontributeis the remaining gap.Impact
On a long-lived milestone, which is exactly what milestones are designed for, a single archived early contribution makes every later
contribute()call panic instead of returningError::ContributionNotFound. Crowdfunding for that milestone is blocked until someone callskeep_alive, and callers don't get a typed error explaining why.Suggested fix
Replace both calls with
.ok_or(Error::ContributionNotFound)?, and add an archived-record test forcontribute.Related: #103, #318. The escrow counterpart is filed separately.