feat: add Solscan wallet analytics tools - #250
Conversation
|
@Florcitaq is attempting to deploy a commit to the Neur Team on Vercel. A member of the Team first needs to authorize it. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds Solscan analytics support with server-side API wrappers, AI tools that render transactions/DeFi/portfolio data, registry wiring, and new environment variables. ChangesSolscan Integration
Estimated code review effort: 3 (Moderate) | ~25 minutes 🚥 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 |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
src/server/actions/solscan.ts (2)
87-91: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win
solscanResponseSchema.parsecan throw a rawZodErrorthat propagates to the user-facing error message.If Solscan returns an unexpected shape,
.parse()throws aZodError; since it's anErrorinstance, callers insrc/ai/solana/solscan.tsx(error instanceof Error ? error.message : ...) will surface the verbose Zod validation message directly to the end user instead of a clean fallback message.🤖 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 `@src/server/actions/solscan.ts` around lines 87 - 91, The Solscan response parsing in solscanResponseSchema.parse is allowed to throw a raw ZodError, which then bubbles up as the user-facing message. Update the parsing flow in the Solscan action to catch schema validation failures and convert them into a clean fallback error before throwing, so callers like the Solscan UI path see a generic “request failed” message instead of the verbose Zod details. Use the existing parsed handling in the Solscan action to keep the error contract consistent.
96-153: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win
cache()won’t dedupe these calls as written.React.cachekeys by argument identity, and these call sites pass a fresh object literal on each invocation, so repeated calls miss unless the exact same object instance is reused. Switch these helpers to primitive parameters or reuse a stable argument object if request-level memoization is the goal.🤖 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 `@src/server/actions/solscan.ts` around lines 96 - 153, `cache()` is not deduping these Solscan helpers because each call passes a new object literal, so repeated requests miss memoization. Update the `getSolscanAccountTransactions`, `getSolscanAccountDefiActivities`, and `getSolscanAccountPortfolio` wrappers to use stable primitive arguments (or otherwise reuse a shared argument object) so `cache` can key them consistently and dedupe identical calls.src/ai/solana/solscan.tsx (1)
200-206: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value
renderResultcastsrawwithout runtime validation.
raw as { success: boolean; data?: T; error?: string }blindly trusts the shape returned byexecute. Sinceexecutealways constructs this shape internally, the risk is low, but a lightweight Zod check would guard against future drift betweenexecutereturn shapes andrenderexpectations.🤖 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 `@src/ai/solana/solscan.tsx` around lines 200 - 206, `renderResult` in `solscan.tsx` is trusting `raw` via a type cast without validating the runtime shape. Add a lightweight Zod schema (or equivalent runtime guard) inside `renderResult` to validate the `{ success, data, error }` structure before accessing it, and only call the `render` callback when the parsed value is valid; otherwise fall back to `ErrorCard`. Use `renderResult` and the `execute` result shape as the key symbols to update.
🤖 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 `@src/server/actions/solscan.ts`:
- Around line 96-112: The `getSolscanAccountTransactions` helper is clamping
`limit` to a minimum of 10, which overrides valid smaller caller values. Update
the `Math.max(10, Math.min(limit, 40))` logic in `getSolscanAccountTransactions`
so it preserves requested limits down to the lower bound accepted by the
caller/schema, while still enforcing the upper cap of 40. Keep the change
localized to this function and ensure the `limit` defaulting behavior remains
intact.
- Around line 75-85: The Solscan request in the fetch flow has no timeout, so a
hanging upstream call can block callers indefinitely. Update the outbound
request in the Solscan action to use an AbortController or equivalent timeout
wrapper around the fetch call, and make sure the timeout is applied alongside
the existing next revalidate and headers options. Keep the existing response
handling in the same flow so the timeout failure is surfaced clearly from the
Solscan request path.
---
Nitpick comments:
In `@src/ai/solana/solscan.tsx`:
- Around line 200-206: `renderResult` in `solscan.tsx` is trusting `raw` via a
type cast without validating the runtime shape. Add a lightweight Zod schema (or
equivalent runtime guard) inside `renderResult` to validate the `{ success,
data, error }` structure before accessing it, and only call the `render`
callback when the parsed value is valid; otherwise fall back to `ErrorCard`. Use
`renderResult` and the `execute` result shape as the key symbols to update.
In `@src/server/actions/solscan.ts`:
- Around line 87-91: The Solscan response parsing in solscanResponseSchema.parse
is allowed to throw a raw ZodError, which then bubbles up as the user-facing
message. Update the parsing flow in the Solscan action to catch schema
validation failures and convert them into a clean fallback error before
throwing, so callers like the Solscan UI path see a generic “request failed”
message instead of the verbose Zod details. Use the existing parsed handling in
the Solscan action to keep the error contract consistent.
- Around line 96-153: `cache()` is not deduping these Solscan helpers because
each call passes a new object literal, so repeated requests miss memoization.
Update the `getSolscanAccountTransactions`, `getSolscanAccountDefiActivities`,
and `getSolscanAccountPortfolio` wrappers to use stable primitive arguments (or
otherwise reuse a shared argument object) so `cache` can key them consistently
and dedupe identical calls.
🪄 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: 6cbc69d8-a7c4-4dda-9a54-f15f5a2690a5
📒 Files selected for processing (4)
.env.examplesrc/ai/providers.tsxsrc/ai/solana/solscan.tsxsrc/server/actions/solscan.ts
|
Addressed the CodeRabbit review in �8a7765:
Verification:
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@src/server/actions/solscan.ts`:
- Around line 88-90: The non-2xx handling in the Solscan request path is
dropping the API’s JSON error payload and only throwing the status code. Update
the response handling in the Solscan action flow so the code in the
request/parse block reads the JSON body when response.ok is false, then prefers
errors.message from the Solscan payload in the thrown Error. Keep the existing
request flow intact and ensure the thrown message still falls back to the HTTP
status if no API message is present.
🪄 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: abc40c9f-5db4-460f-b761-87fbe138ebdc
📒 Files selected for processing (2)
src/ai/solana/solscan.tsxsrc/server/actions/solscan.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- src/ai/solana/solscan.tsx
|
Addressed the follow-up CodeRabbit comment in 3e295f5:
Verification:
|
Closes #47.
Summary
Verification
Summary by CodeRabbit
SOLSCAN_API_KEY,SOLSCAN_BASE_URL).