Skip to content

fix: Make inherit_milestones actually copy milestone data #875

Description

@Samuel1505

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

  1. Read contracts/ContributionGuide.md for the contribution workflow.
  2. Comment on the issue to claim it before starting.
  3. Branch: fix/issue-930-fork-inherit-milestones.
  4. Run cargo fmt, cargo clippy -- -D warnings, cargo test before opening your PR.
  5. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions