fix(governance): scope DTF settings validation to changes - #1084
Conversation
|
Warning Review limit reached
Next review available in: 51 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
📝 WalkthroughWalkthroughDTF settings proposal validation now checks errors only for changed settings. Proposal confirmation uses this scoped validation state. Unit tests, E2E coverage, and project records document the behavior. ChangesDTF Settings Validation
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant ProposalInstructions
participant useHasRelevantFormErrors
participant hasRelevantFormErrors
participant ConfirmProposalButton
ProposalInstructions->>useHasRelevantFormErrors: provide form errors
useHasRelevantFormErrors->>hasRelevantFormErrors: provide errors and changed settings
hasRelevantFormErrors-->>ProposalInstructions: return relevant error state
ProposalInstructions->>ConfirmProposalButton: provide canProceed
ConfirmProposalButton-->>ProposalInstructions: block or allow confirmation
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@e2e/tests/flows/governance-propose-dtf-settings.spec.ts`:
- Around line 144-155: Replace the translated-copy selectors in the governance
flow with kebab-case data-testid selectors: update the assertions for “Remaining
allocation: 22.23%” and “Basics Update”, and the mandate field lookup around
snapshot.mandate, using the corresponding test IDs exposed by those elements
while preserving the existing interactions and assertions.
In
`@src/views/index-dtf/governance/views/propose/views/propose-dtf-settings/components/dtf-settings-proposal-overview.tsx`:
- Around line 23-37: Update ConfirmProposalButton so the button remains enabled
when isProposalConfirmed is true, even if canProceed is false, allowing the user
to unconfirm and edit the proposal. Preserve the existing disabled state for
unconfirmed proposals that cannot proceed and keep handleConfirm’s transition
logic unchanged.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: fd5ed738-60c8-4980-9f52-ce2c8c229b96
📒 Files selected for processing (10)
docs/wiki/log.mddocs/wiki/progress.mde2e/TEST_MAP.mde2e/tests/flows/governance-propose-dtf-settings.spec.tssrc/views/index-dtf/governance/views/propose/views/propose-dtf-settings/atoms.tssrc/views/index-dtf/governance/views/propose/views/propose-dtf-settings/components/dtf-settings-proposal-overview.tsxsrc/views/index-dtf/governance/views/propose/views/propose-dtf-settings/hooks/has-relevant-form-errors.tssrc/views/index-dtf/governance/views/propose/views/propose-dtf-settings/hooks/tests/use-has-relevant-form-errors.test.tssrc/views/index-dtf/governance/views/propose/views/propose-dtf-settings/hooks/use-has-relevant-form-errors.tssrc/views/index-dtf/governance/views/propose/views/propose-dtf-settings/updater.tsx
💤 Files with no reviewable changes (1)
- src/views/index-dtf/governance/views/propose/views/propose-dtf-settings/atoms.ts
Deploying register-app with
|
| Latest commit: |
0e3de80
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://de55db5f.register-app.pages.dev |
| Branch Preview URL: | https://fix-dtf-settings-confirm-but.register-app.pages.dev |
2 participants
Bug Description
On the DTF Settings proposal page, Confirm & prepare proposal remained disabled after a valid change when an unchanged on-chain setting failed the form's deploy-time validation. The reported SMEL DTF reproduces this through fee-distribution rounding drift.
Root Cause
The confirm gate used
formState.isValid, which validates every seeded setting. Existing on-chain values can fall outside the UI schema or lose precision when displayed, even though unchanged settings are omitted from proposal calldata. An unrelated valid change was therefore blocked by an error that would not be proposed.Fix
How to Verify
Test Plan
Risk Assessment
Medium — this changes a governance proposal gate. Proposal calldata construction is unchanged, and validation still blocks errors tied to changed settings. Engineer review is required before merge.
Summary by CodeRabbit