Conversation
|
No actionable comments were generated in the recent review. 🎉 📝 WalkthroughWalkthroughRefactored proposal voting auth to use a centralized auth context, selected the latest ECENCY-created active proposal by highest proposal_id, simplified broadcast/mutation and retry/error handling, and added a render guard when the active proposal id is missing. Changes
Sequence Diagram(s)mermaid Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 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 |
There was a problem hiding this comment.
🧹 Nitpick comments (2)
src/providers/queries/proposalQueries.ts (1)
100-108: Duplicate operation definition — consider extracting a shared builder.The
update_proposal_votesoperation object is defined identically in both theuseBroadcastMutationbuilder (lines 82–91) and themutationFn(lines 100–108). If one changes without the other, voting could break silently for certain auth types.♻️ Extract a shared operation builder
export const useProposalVoteMutation = () => { const dispatch = useAppDispatch(); const intl = useIntl(); const { executeOperation } = useActiveKeyOperation(); const currentAccount = useAppSelector(selectCurrentAccount); const auth = useAuthContext(); + const buildOperations = (proposalId: number) => [ + [ + 'update_proposal_votes', + { + voter: currentAccount.name, + proposal_ids: [proposalId], + approve: true, + extensions: [], + }, + ], + ]; + const broadcastMutation = useBroadcastMutation<{ proposalId: number }>( ['proposals', 'vote'], currentAccount.name, - ({ proposalId }) => [ - [ - 'update_proposal_votes', - { - voter: currentAccount.name, - proposal_ids: [proposalId], - approve: true, - extensions: [], - }, - ], - ], + ({ proposalId }) => buildOperations(proposalId), () => {}, auth, 'active', ); return useMutation<any, Error, { proposalId: number }>({ mutationFn: async ({ proposalId }) => { - const operation = [ - 'update_proposal_votes', - { - voter: currentAccount.name, - proposal_ids: [proposalId], - approve: true, - extensions: [],, - }, - ]; - return executeOperation({ - operations: [operation], + operations: buildOperations(proposalId), privateKeyHandler: async () => { return broadcastMutation.mutateAsync({ proposalId }); },🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/providers/queries/proposalQueries.ts` around lines 100 - 108, Duplicate construction of the update_proposal_votes operation is present in both the useBroadcastMutation builder and the mutationFn; extract a single helper like buildUpdateProposalVotes(voter, proposalIds, approve) and replace both inline operation arrays with calls to that helper, passing currentAccount.name and [proposalId] (and approve: true) so both code paths use the identical operation payload (ensure the helper returns the exact array shape used by update_proposal_votes).src/components/proposalVoteRequest/container/proposalVoteRequest.tsx (1)
68-70: Consider a non-null assertion or type guard for_ecencyProposalId.While the
skipRenderguard on line 51 ensures_ecencyProposalIdis truthy at runtime before_voteActioncan be called, TypeScript won't narrow the type through theuseMemo→ early-return indirection. This means_ecencyProposalIdis still typed asnumber | undefinedon line 69, which may produce a type error when passed tomutate({ proposalId: number }).🔧 Suggested fix
const _voteAction = () => { - proposalVoteMutation.mutate({ proposalId: _ecencyProposalId }); + proposalVoteMutation.mutate({ proposalId: _ecencyProposalId! }); };Or, for a safer alternative, add an explicit guard:
const _voteAction = () => { + if (!_ecencyProposalId) return; proposalVoteMutation.mutate({ proposalId: _ecencyProposalId }); };🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/components/proposalVoteRequest/container/proposalVoteRequest.tsx` around lines 68 - 70, The call to proposalVoteMutation.mutate passes _ecencyProposalId which is typed number | undefined; update the _voteAction function to ensure a non-null number is passed by either using a non-null assertion (e.g. _ecencyProposalId!) or an explicit guard/early return that checks typeof _ecencyProposalId === 'number' before calling mutate; reference the existing _voteAction, _ecencyProposalId and proposalVoteMutation symbols so the compiler sees a narrowed type when calling mutate.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@src/components/proposalVoteRequest/container/proposalVoteRequest.tsx`:
- Around line 68-70: The call to proposalVoteMutation.mutate passes
_ecencyProposalId which is typed number | undefined; update the _voteAction
function to ensure a non-null number is passed by either using a non-null
assertion (e.g. _ecencyProposalId!) or an explicit guard/early return that
checks typeof _ecencyProposalId === 'number' before calling mutate; reference
the existing _voteAction, _ecencyProposalId and proposalVoteMutation symbols so
the compiler sees a narrowed type when calling mutate.
In `@src/providers/queries/proposalQueries.ts`:
- Around line 100-108: Duplicate construction of the update_proposal_votes
operation is present in both the useBroadcastMutation builder and the
mutationFn; extract a single helper like buildUpdateProposalVotes(voter,
proposalIds, approve) and replace both inline operation arrays with calls to
that helper, passing currentAccount.name and [proposalId] (and approve: true) so
both code paths use the identical operation payload (ensure the helper returns
the exact array shape used by update_proposal_votes).
Summary by CodeRabbit
Bug Fixes
Refactor