fixed fb kyc upload issue and other minor changes - #63
Merged
Conversation
Contributor
|
Warning Review limit reached
Next review available in: 37 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. 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: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughIntroduces a ChangesbaseUrl Config, Safe Balance Helpers, and RPC Hardening
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
RushabhParmar12
previously approved these changes
Jun 30, 2026
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 8
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
app/components/voters/View.vue (1)
674-678: 🩺 Stability & Availability | 🟡 Minor | ⚡ Quick winDo not throw from the async balance callback.
This throw is outside the surrounding
try/catchand can become an unhandled async error. Log the error and keep the safe"0"fallback instead.Proposed fix
self.getBalanceSafeCallback(voter, 'voters/View.vue - created', function (a, b) { - self.balance = new BigNumber(b).div(10 ** 18).toNumber() if (a) { - throw Error(a) + console.log('got an error', a) + return } + self.balance = new BigNumber(b).div(10 ** 18).toNumber() })🤖 Prompt for 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. In `@app/components/voters/View.vue` around lines 674 - 678, In View.vue’s created balance callback inside getBalanceSafeCallback, do not throw when a is present because it escapes the surrounding try/catch and can surface as an unhandled async error. Update the callback to log the error through the existing error handling path, and preserve the safe "0" fallback behavior in self.balance assignment so the voter view still renders safely.
🧹 Nitpick comments (1)
app/app.js (1)
725-733: 🎯 Functional Correctness | 🔵 Trivial | 💤 Low valueWrap both
casedeclarations in blocks. Biome’snoSwitchDeclarationsrule applies here and insignMessage; adding{}around each case keeps the lexical scope explicit.🤖 Prompt for 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. In `@app/app.js` around lines 725 - 733, Wrap the declarations in the trezor branch of the switch in a block, since Biome’s noSwitchDeclarations rule is triggered by lexical bindings directly under a case label. Update the trezor case in the same way as signMessage by enclosing the case body in braces so trezorPayload, trezorOffset, and account stay within an explicit scope.Source: Linters/SAST tools
🤖 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 `@apis/voters.js`:
- Around line 267-275: The logging in sendSignedTransaction is exposing
sensitive wallet data, including signedAddress, action/amount, and exact
balances from web3.eth.getBalance. Update this flow to remove or redact these
values from normal server logs, and only emit them behind an explicit debug flag
or debug-level logger. Keep the diagnostic context in sendSignedTransaction, but
ensure the console.log statements in the vote path no longer print raw addresses
or precise balance amounts.
- Around line 271-277: The balance selection in voters.js is incorrectly using
the 0x result directly in the fallback expression, so a `"0"` balance blocks the
XDC balance and any getBalance failure prevents fallback entirely. Update the
logic around the signedAddress/xdcAddress balance lookup so the code explicitly
treats a zero 0x balance as empty and falls back to the XDC value, and wrap the
web3.eth.getBalance calls in a way that still uses balanceXdc if the 0x lookup
throws. Keep the change near the existing getBalance logging and the final
balance assignment.
In `@app/app.js`:
- Around line 839-880: The current getBalanceSafe flow in
Vue.prototype.getBalanceSafe swallows every getBalance error and returns '0'
even when all RPC reads fail. Update the method to track whether any balance
lookup succeeded across both this.web3 and getChainReadWeb3, and if none do,
throw an error instead of returning zero. Keep the existing zero-vs-fallback
selection logic for successful reads, and ensure getBalanceSafeCallback can
surface the thrown failure path.
- Around line 515-522: The wallet reset flow in resetWalletConnectProvider is
not handling the Promise returned by instance.disconnect(), so a rejection can
escape even though it is wrapped in try/catch. Update the disconnect handling in
resetWalletConnectProvider to await the returned Promise or attach a catch
handler, and make sure any failure is swallowed or logged consistently with the
existing closeWalletConnectModal(instance).catch(...) behavior.
In `@app/components/candidates/Apply.vue`:
- Around line 670-674: The fee balance check in Apply.vue’s KYC upload flow
happens too late, after the KYC file has already been posted. Add a conservative
preflight balance check in the same uploadKYC path before the file upload step,
using getBalanceSafe, gas, and gasPrice to estimate the required fee. If the
account balance is insufficient, stop early and surface the existing error path
so users do not send KYC data that cannot be anchored on-chain.
In `@crawl.js`:
- Around line 201-205: The status/owner fallback logic in getCurrentCandidates
is reading from candateInDB after the DB record has already been removed, so it
loses the pre-removal snapshot. Update the status resolution to use the captured
previous candidate state (prevCandidates/prevStatus) instead of
candateInDB.status, and pass the captured owner through as the fallback source
when the owner RPC fails. Make the same snapshot-based fallback change in the
related owner handling code so reactivated candidates don’t stay RESIGNED and
existing owner values aren’t cleared.
- Around line 380-385: The candidate node response validation in crawl.js is too
shallow: `candidateAddressData.data.result` can be present while `Masternodes`,
`Penalty`, or `Standbynodes` are missing or not arrays, which later breaks the
`.includes` checks. Update the validation around the
`candidateAddressData.data.result` destructuring in the
`XDPoS_getMasternodesByNumber` flow to verify each of `masterNodes`,
`slashNodes`, and `standByNodes` is a real array before continuing, and
log/return early when any are invalid.
- Around line 372-378: The RPC call in the crawler currently uses axios.post
without any request timeout, so an unresponsive endpoint can hang the flow
before rpcErr is ever caught. Update the axios.post call in the
candidateAddressData fetch block to include a reasonable timeout via the request
config, and keep the existing catch/logging path in place so the crawler fails
fast and continues handling RPC errors cleanly.
---
Outside diff comments:
In `@app/components/voters/View.vue`:
- Around line 674-678: In View.vue’s created balance callback inside
getBalanceSafeCallback, do not throw when a is present because it escapes the
surrounding try/catch and can surface as an unhandled async error. Update the
callback to log the error through the existing error handling path, and preserve
the safe "0" fallback behavior in self.balance assignment so the voter view
still renders safely.
---
Nitpick comments:
In `@app/app.js`:
- Around line 725-733: Wrap the declarations in the trezor branch of the switch
in a block, since Biome’s noSwitchDeclarations rule is triggered by lexical
bindings directly under a case label. Update the trezor case in the same way as
signMessage by enclosing the case body in braces so trezorPayload, trezorOffset,
and account stay within an explicit scope.
🪄 Autofix (Beta)
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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 69ef5d08-5799-4078-90bd-83b4922a2f66
📒 Files selected for processing (14)
apis/config.jsapis/voters.jsapp/app.jsapp/components/Setting.vueapp/components/candidates/Apply.vueapp/components/candidates/View.vueapp/components/voters/View.vueapp/components/voters/Voting.vuecrawl.jselect.jshelpers/personalSign.jshelpers/twitter.jsindex.jsmiddlewares/sitemap.js
RushabhParmar12
approved these changes
Jun 30, 2026
AnilChinchawale
approved these changes
Jun 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
New Features
Bug Fixes