Description
fork_grant (contracts/contracts/stellar-grants/src/fork.rs, lines 9-83) accepts an inherit_milestones: bool parameter (line 18), but it has no effect on what actually gets copied:
let new_grant_id = crate::internal_grant_create(
env, caller, new_title, new_description, new_token,
new_total_amount, original.milestone_amount, original.total_milestones, reviewers,
)?; // total_milestones is copied unconditionally, regardless of inherit_milestones
...
if inherit_milestones {
inherited_fields.push_back(String::from_str(env, "milestones")); // this is the ONLY effect of the flag
}
inherit_milestones only ever controls whether the string "milestones" is appended to ForkRecord.inherited_fields (confirmed by grepping every use of the parameter in the file) — it never gates any actual per-milestone data copy. No Milestone record (description, proof_url, state) is ever copied in either branch, and total_milestones (just the count) is copied unconditionally either way.
ForkRecord.inherited_fields is a permanent on-chain record (readable via get_fork_record) meant to describe what was inherited from the original grant. A caller forking with inherit_milestones = true gets a record falsely claiming milestone content was inherited, when in fact no milestone data was ever copied — any off-chain indexer, auditor, or future contract logic trusting this field to determine grant lineage/provenance is misled.
Technical Requirements
Files to update
contracts/contracts/stellar-grants/src/fork.rs (fork_grant, lines 9-83)
Fix direction
Either implement the real behavior the flag promises — when inherit_milestones is true, copy each of the original grant's Milestone records (description, proof requirements, etc., but not approval state/proofs, which shouldn't carry over to a new grant) onto the new grant — or, if milestone content inheritance isn't actually intended to be supported yet, remove the misleading claim from ForkRecord.inherited_fields until the feature is implemented (don't push "milestones" onto inherited_fields unless real milestone data was actually copied).
Acceptance Criteria
ForkRecord.inherited_fields only ever includes "milestones" when milestone content was genuinely copied to the new grant.
- If milestone copying is implemented: a test forks a grant with
inherit_milestones = true and asserts the new grant's milestones match the original's descriptions/requirements.
- If the claim is instead removed until implemented: a test asserts
inherited_fields does not contain "milestones" regardless of the flag's value, with a follow-up issue/TODO noting the feature is not yet implemented.
cargo test passes.
Estimated Effort
Beginner: 4 hours
Intermediate: 2 hours
Expert: 1 hour
How to work this issue
- Read
contracts/ContributionGuide.md for the contribution workflow.
- Comment on the issue to claim it before starting.
- Branch:
fix/issue-930-fork-inherit-milestones.
- Run
cargo fmt, cargo clippy -- -D warnings, cargo test before opening your PR.
- Use a Conventional Commit message, e.g.
fix: make inherit_milestones actually copy milestone data or stop claiming it does.
Before you start
If you find this project interesting, please consider starring the repository on GitHub. It helps the project gain visibility and supports the Drips Wave program that rewards contributors for merged fixes like this one.
Description
fork_grant(contracts/contracts/stellar-grants/src/fork.rs, lines 9-83) accepts aninherit_milestones: boolparameter (line 18), but it has no effect on what actually gets copied:inherit_milestonesonly ever controls whether the string"milestones"is appended toForkRecord.inherited_fields(confirmed by grepping every use of the parameter in the file) — it never gates any actual per-milestone data copy. NoMilestonerecord (description, proof_url, state) is ever copied in either branch, andtotal_milestones(just the count) is copied unconditionally either way.ForkRecord.inherited_fieldsis a permanent on-chain record (readable viaget_fork_record) meant to describe what was inherited from the original grant. A caller forking withinherit_milestones = truegets a record falsely claiming milestone content was inherited, when in fact no milestone data was ever copied — any off-chain indexer, auditor, or future contract logic trusting this field to determine grant lineage/provenance is misled.Technical Requirements
Files to update
contracts/contracts/stellar-grants/src/fork.rs(fork_grant, lines 9-83)Fix direction
Either implement the real behavior the flag promises — when
inherit_milestonesis true, copy each of the original grant'sMilestonerecords (description, proof requirements, etc., but not approval state/proofs, which shouldn't carry over to a new grant) onto the new grant — or, if milestone content inheritance isn't actually intended to be supported yet, remove the misleading claim fromForkRecord.inherited_fieldsuntil the feature is implemented (don't push"milestones"ontoinherited_fieldsunless real milestone data was actually copied).Acceptance Criteria
ForkRecord.inherited_fieldsonly ever includes"milestones"when milestone content was genuinely copied to the new grant.inherit_milestones = trueand asserts the new grant's milestones match the original's descriptions/requirements.inherited_fieldsdoes not contain"milestones"regardless of the flag's value, with a follow-up issue/TODO noting the feature is not yet implemented.cargo testpasses.Estimated Effort
Beginner: 4 hours
Intermediate: 2 hours
Expert: 1 hour
How to work this issue
contracts/ContributionGuide.mdfor the contribution workflow.fix/issue-930-fork-inherit-milestones.cargo fmt,cargo clippy -- -D warnings,cargo testbefore opening your PR.fix: make inherit_milestones actually copy milestone data or stop claiming it does.Before you start
If you find this project interesting, please consider starring the repository on GitHub. It helps the project gain visibility and supports the Drips Wave program that rewards contributors for merged fixes like this one.