[dashboard] add solana policies to vault access token #8239
Conversation
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. |
WalkthroughAdds Solana-specific policy entries to access token creation for wallets and management tokens, expanding allowed actions without altering function signatures or control flow. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
apps/dashboard/src/app/(app)/team/[team_slug]/[project_slug]/(sidebar)/transactions/lib/vault.client.ts(2 hunks)
🧰 Additional context used
📓 Path-based instructions (4)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.{ts,tsx}: Write idiomatic TypeScript with explicit function declarations and return types
Limit each file to one stateless, single-responsibility function for clarity
Re-use shared types from@/typesor localtypes.tsbarrels
Prefer type aliases over interface except for nominal shapes
Avoidanyandunknownunless unavoidable; narrow generics when possible
Choose composition over inheritance; leverage utility types (Partial,Pick, etc.)
Comment only ambiguous logic; avoid restating TypeScript in prose
**/*.{ts,tsx}: Use explicit function declarations and explicit return types in TypeScript
Limit each file to one stateless, single‑responsibility function
Re‑use shared types from@/typeswhere applicable
Prefertypealiases overinterfaceexcept for nominal shapes
Avoidanyandunknownunless unavoidable; narrow generics when possible
Prefer composition over inheritance; use utility types (Partial, Pick, etc.)
Lazy‑import optional features and avoid top‑level side‑effects to reduce bundle size
Files:
apps/dashboard/src/app/(app)/team/[team_slug]/[project_slug]/(sidebar)/transactions/lib/vault.client.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (CLAUDE.md)
Load heavy dependencies inside async paths to keep initial bundle lean (lazy loading)
Files:
apps/dashboard/src/app/(app)/team/[team_slug]/[project_slug]/(sidebar)/transactions/lib/vault.client.ts
apps/{dashboard,playground-web}/**/*.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
apps/{dashboard,playground-web}/**/*.{ts,tsx}: Import UI primitives from@/components/ui/*(Button, Input, Select, Tabs, Card, Sidebar, Badge, Separator) in dashboard and playground apps
UseNavLinkfor internal navigation with automatic active states in dashboard and playground apps
Use Tailwind CSS only – no inline styles or CSS modules
Usecn()from@/lib/utilsfor conditional class logic
Use design system tokens (e.g.,bg-card,border-border,text-muted-foreground)
Server Components (Node edge): Start files withimport "server-only";
Client Components (browser): Begin files with'use client';
Always callgetAuthToken()to retrieve JWT from cookies on server side
UseAuthorization: Bearerheader – never embed tokens in URLs
Return typed results (e.g.,Project[],User[]) – avoidany
Wrap client-side data fetching calls in React Query (@tanstack/react-query)
Use descriptive, stablequeryKeysfor React Query cache hits
ConfigurestaleTime/cacheTimein React Query based on freshness (default ≥ 60s)
Keep tokens secret via internal API routes or server actions
Never importposthog-jsin server components
Files:
apps/dashboard/src/app/(app)/team/[team_slug]/[project_slug]/(sidebar)/transactions/lib/vault.client.ts
apps/{dashboard,playground}/**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
apps/{dashboard,playground}/**/*.{ts,tsx}: Import UI primitives from@/components/ui/_(e.g., Button, Input, Tabs, Card)
UseNavLinkfor internal navigation to get active state handling
Use Tailwind CSS for styling; no inline styles
Merge class names withcn()from@/lib/utilsfor conditional classes
Stick to design tokens (e.g., bg-card, border-border, text-muted-foreground)
Server Components must start withimport "server-only"; usenext/headers, server‑only env, heavy data fetching, andredirect()where appropriate
Client Components must start with'use client'; handle interactivity with hooks and browser APIs
Server-side data fetching: callgetAuthToken()from cookies, sendAuthorization: Bearer <token>header, and return typed results (avoidany)
Client-side data fetching: wrap calls in React Query with descriptive, stablequeryKeysand set sensiblestaleTime/cacheTime(≥ 60s default); keep tokens secret via internal routes or server actions
Do not importposthog-jsin server components (client-side only)
Files:
apps/dashboard/src/app/(app)/team/[team_slug]/[project_slug]/(sidebar)/transactions/lib/vault.client.ts
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Size
- GitHub Check: Unit Tests
- GitHub Check: Analyze (javascript)
| { | ||
| metadataPatterns: [ | ||
| { | ||
| key: "projectId", | ||
| rule: { | ||
| pattern: props.project.id, | ||
| }, | ||
| }, | ||
| { | ||
| key: "teamId", | ||
| rule: { | ||
| pattern: props.project.teamId, | ||
| }, | ||
| }, | ||
| { | ||
| key: "type", | ||
| rule: { | ||
| pattern: "server-wallet", | ||
| }, | ||
| }, | ||
| ], | ||
| type: "solana:read", | ||
| }, | ||
| { | ||
| requiredMetadataPatterns: [ | ||
| { | ||
| key: "projectId", | ||
| rule: { | ||
| pattern: props.project.id, | ||
| }, | ||
| }, | ||
| { | ||
| key: "teamId", | ||
| rule: { | ||
| pattern: props.project.teamId, | ||
| }, | ||
| }, | ||
| { | ||
| key: "type", | ||
| rule: { | ||
| pattern: "server-wallet", | ||
| }, | ||
| }, | ||
| ], | ||
| type: "solana:create", | ||
| }, | ||
| { | ||
| metadataPatterns: [ | ||
| { | ||
| key: "projectId", | ||
| rule: { | ||
| pattern: props.project.id, | ||
| }, | ||
| }, | ||
| { | ||
| key: "teamId", | ||
| rule: { | ||
| pattern: props.project.teamId, | ||
| }, | ||
| }, | ||
| { | ||
| key: "type", | ||
| rule: { | ||
| pattern: "server-wallet", | ||
| }, | ||
| }, | ||
| ], | ||
| type: "solana:signTransaction", | ||
| }, | ||
| { | ||
| metadataPatterns: [ | ||
| { | ||
| key: "projectId", | ||
| rule: { | ||
| pattern: props.project.id, | ||
| }, | ||
| }, | ||
| { | ||
| key: "teamId", | ||
| rule: { | ||
| pattern: props.project.teamId, | ||
| }, | ||
| }, | ||
| { | ||
| key: "type", | ||
| rule: { | ||
| pattern: "server-wallet", | ||
| }, | ||
| }, | ||
| ], | ||
| type: "solana:signMessage", | ||
| }, |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Approve Solana wallet policies with refactor recommendation.
The Solana policy additions correctly mirror the existing EVM policy structure and will enable Solana wallet operations. However, the identical metadataPatterns structure across all policies creates significant duplication.
Consider extracting a helper function to generate policy objects:
function createWalletPolicy(
type: string,
projectId: string,
teamId: string,
additionalOptions?: Record<string, unknown>
) {
const metadataPatterns = [
{ key: "projectId", rule: { pattern: projectId } },
{ key: "teamId", rule: { pattern: teamId } },
{ key: "type", rule: { pattern: "server-wallet" } },
];
return {
...(type.includes(":create")
? { requiredMetadataPatterns: metadataPatterns }
: { metadataPatterns }),
type,
...additionalOptions,
};
}Then replace the policy blocks:
policies: [
// EVM policies
createWalletPolicy("eoa:read", props.project.id, props.project.teamId),
createWalletPolicy("eoa:create", props.project.id, props.project.teamId),
createWalletPolicy("eoa:signMessage", props.project.id, props.project.teamId),
createWalletPolicy("eoa:signTransaction", props.project.id, props.project.teamId, {
payloadPatterns: {}
}),
// ... other EVM policies
// Solana policies
createWalletPolicy("solana:read", props.project.id, props.project.teamId),
createWalletPolicy("solana:create", props.project.id, props.project.teamId),
createWalletPolicy("solana:signTransaction", props.project.id, props.project.teamId),
createWalletPolicy("solana:signMessage", props.project.id, props.project.teamId),
]This would also address the pre-existing duplicate eoa:read and eoa:create policies at lines 351-396 and 517-562.
🤖 Prompt for AI Agents
In
apps/dashboard/src/app/(app)/team/[team_slug]/[project_slug]/(sidebar)/transactions/lib/vault.client.ts
around lines 563-654, the four Solana policy objects repeat identical
metadataPatterns causing duplication; extract a small helper (e.g.,
createWalletPolicy) that accepts type, projectId, teamId and optional extra
options, builds the common metadataPatterns and returns either metadataPatterns
or requiredMetadataPatterns for create types, then replace the repeated Solana
policy blocks with calls to that helper (and likewise replace the duplicated EVM
eoa:read/eoa:create blocks at lines ~351-396 and ~517-562) to deduplicate and
keep payload-specific options passed through the helper.
| { | ||
| metadataPatterns: [ | ||
| { | ||
| key: "projectId", | ||
| rule: { | ||
| pattern: props.project.id, | ||
| }, | ||
| }, | ||
| { | ||
| key: "teamId", | ||
| rule: { | ||
| pattern: props.project.teamId, | ||
| }, | ||
| }, | ||
| { | ||
| key: "type", | ||
| rule: { | ||
| pattern: "server-wallet", | ||
| }, | ||
| }, | ||
| ], | ||
| type: "solana:read", | ||
| }, | ||
| { | ||
| requiredMetadataPatterns: [ | ||
| { | ||
| key: "projectId", | ||
| rule: { | ||
| pattern: props.project.id, | ||
| }, | ||
| }, | ||
| { | ||
| key: "teamId", | ||
| rule: { | ||
| pattern: props.project.teamId, | ||
| }, | ||
| }, | ||
| { | ||
| key: "type", | ||
| rule: { | ||
| pattern: "server-wallet", | ||
| }, | ||
| }, | ||
| ], | ||
| type: "solana:create", | ||
| }, |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Approve Solana management policies.
The Solana management token policies are correctly limited to read and create operations (no signing), which matches the EVM policy structure. This is the appropriate permission model for management tokens.
The same helper function refactor suggested for lines 563-654 would reduce duplication here as well. Both createWalletAccessToken and createManagementAccessToken would benefit from the extracted policy generation helper.
🤖 Prompt for AI Agents
In
apps/dashboard/src/app/(app)/team/[team_slug]/[project_slug]/(sidebar)/transactions/lib/vault.client.ts
around lines 728 to 773, the Solana management token policy blocks are correct
but duplicate policy-building logic; extract a small helper (e.g.,
buildSolanaPolicies(project, teamId, types[] or mode)) that returns the array of
policy objects (metadataPatterns/requiredMetadataPatterns and type) and replace
the inline policy arrays in createWalletAccessToken and
createManagementAccessToken with calls to this helper to remove duplication and
centralize policy construction.
size-limit report 📦
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #8239 +/- ##
=======================================
Coverage 55.02% 55.02%
=======================================
Files 919 919
Lines 60583 60583
Branches 4127 4127
=======================================
Hits 33335 33335
Misses 27145 27145
Partials 103 103
🚀 New features to boost your workflow:
|
2 participants
PR-Codex overview
This PR focuses on enhancing the
vault.client.tsfile by adding new metadata patterns and required metadata patterns for various Solana-related actions.Detailed summary
solana:read,solana:create,solana:signTransaction, andsolana:signMessage.projectId,teamId, and a fixedtypeof "server-wallet".solana:create.Summary by CodeRabbit