Chunk large governance vote submissions#44
Conversation
Split frontend vote relay payloads at the backend per-request entry cap so large operators can submit all signed votes without hitting too_many_entries. Co-authored-by: Cursor <cursoragent@cursor.com>
|
@codex review |
![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.
Reviewed commit: 005d449d31
ℹ️ 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".
| const res = await client.post(VOTE_PATH, { | ||
| proposalHash, | ||
| voteOutcome, | ||
| voteSignal, | ||
| time, | ||
| entries: chunk, | ||
| }); |
There was a problem hiding this comment.
When any later chunk request fails, submitVote throws and discards results from earlier chunks that were already accepted by the backend. This changes the operation from effectively all-or-nothing (single request) to partially committed but reported as total failure, which breaks retry assumptions in callers (they will resend already-submitted entries and show misleading error state). A concrete case is entries.length > 256 where chunk 1 succeeds and chunk 2 hits a transient 429/network error: users see only an error even though some votes were already relayed.
Useful? React with 👍 / 👎.
Return already-accepted chunk results with retryable per-entry failures when a later chunk request fails, instead of hiding partial success behind a top-level error. Co-authored-by: Cursor <cursoragent@cursor.com>
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9d0f108745
ℹ️ 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".
| if (merged.results.length === 0) { | ||
| throw normalized; | ||
| } |
There was a problem hiding this comment.
The partial-failure path decides whether to throw based on merged.results.length === 0, but results is treated as optional/defensive (Array.isArray(data.results)), so a successful earlier chunk with a non-array or omitted results still leaves this at 0. In that case, a later chunk error incorrectly throws and discards already accepted/rejected progress, defeating the new “preserve successful chunks” behavior for mixed backend responses. Use an explicit success flag (or chunkIndex > 0) instead of results.length to detect prior successful chunk submissions.
Useful? React with 👍 / 👎.
Use successful chunk completion rather than returned result rows to decide whether a later chunk failure should preserve partial progress. Co-authored-by: Cursor <cursoragent@cursor.com>
|
@codex review |
|
Codex Review: Didn't find any major issues. Breezy! ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
1 participant
Summary
/gov/votefrontend submissions into 256-entry chunks to match the backend per-request cap.{ accepted, rejected, results }shape so the vote modal behavior is unchanged.Test plan
npm test -- --runTestsByPath src/lib/governanceService.test.js --watchAll=falsenpm run buildnpm test -- --runTestsByPath lib/gov.test.jsinsysnode-backendMade with Cursor