Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| var fundPlan fundtypes.FundPlan | ||
| if err := fundtypes.GetFundPlanCodec().UnmarshalJSON(plan.PlanJSON, &fundPlan); err != nil { | ||
| return nil, fmt.Errorf("invalid stored plan: %w", err) | ||
| } |
There was a problem hiding this comment.
ExecuteFundPlan now attempts to decode the stored plan JSON into a fund FundPlan (fundtypes.GetFundPlanCodec().UnmarshalJSON), but plans are still accepted in CreatePlan so long as the payload is syntactically valid JSON (keeper.go lines 204‑211). Any previously stored or newly submitted plan that uses arbitrary JSON (e.g., missing delegations/payouts or using different field names) will pass proposal submission and voting but will now fail at execution with "invalid stored plan" from these lines, leaving approved proposals unexecutable. Consider validating the JSON against the FundPlan schema at creation/submission time or normalizing it before storing so governance-approved plans don’t get stuck at execution.
Useful? React with 👍 / 👎.
1 participant
No description provided.