Skip to content

fix: missing plasma flag filter#11361

Merged
0xApotheosis merged 1 commit intodevelopfrom
filter-plasma
Dec 11, 2025
Merged

fix: missing plasma flag filter#11361
0xApotheosis merged 1 commit intodevelopfrom
filter-plasma

Conversation

@0xApotheosis
Copy link
Member

@0xApotheosis 0xApotheosis commented Dec 11, 2025

Description

Added missing Plasma feature flag filter in PluginProvider.tsx to exclude PlasmaMainnet from supportedChains when the Plasma feature flag is disabled.

When the Plasma chain was recently added, the implementation included the feature flag and plugin, but the corresponding filter in PluginProvider.tsx was missing. This caused a runtime error because:

  • The chain adapter was correctly skipped (plugin's feature flag check worked)
  • But PlasmaMainnet was still included in supportedChains (no filter excluded it)
  • When code tried to use this chain ID, it couldn't find the adapter → chain adapter not found for chain id eip155:9745

Issue (if applicable)

Unblocks current release: https://discord.com/channels/554694662431178782/1448483680094912633/1448496038368247880

Risk

Low Risk - This is a one-line addition that follows the exact same pattern as all other feature-flagged chains in the same file. The change simply adds the missing guard for Plasma that was already in place for Optimism, Polygon, Gnosis, Monad, BSC, etc.

What protocols, transaction types, wallets or contract interactions might be affected by this PR?

None. This fix only affects the feature flag gating logic and prevents an error when Plasma is disabled.

Testing

Engineering

When VITE_FEATURE_PLASMA=false we should have no runtime errors.

Operations

  • [] 🏁 My feature is behind a flag and doesn't require operations testing (yet)

We should have no runtime errors in release (where the plasma flag is off)

Screenshots (if applicable)

N/A - This is a bug fix with no UI changes.


Note

Add missing Plasma feature flag check to exclude KnownChainIds.PlasmaMainnet from supportedChains when disabled.

Written by Cursor Bugbot for commit f6e730a. This will update automatically on new commits. Configure here.

Summary by CodeRabbit

  • New Features
    • Plasma blockchain support is now gated behind a feature flag for controlled rollout and deployment.

✏️ Tip: You can customize this high-level summary in your review settings.

@0xApotheosis 0xApotheosis requested a review from a team as a code owner December 11, 2025 02:47
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 11, 2025

📝 Walkthrough

Walkthrough

A feature flag gate for Plasma is added to the PluginProvider's supported chains logic. When PlasmaMainnet is detected, the chain returns false if the Plasma feature flag is disabled, following the existing pattern used for other chains.

Changes

Cohort / File(s) Summary
Feature flag gating for Plasma
src/context/PluginProvider/PluginProvider.tsx
Adds conditional check in _supportedChains computation to gate PlasmaMainnet support behind featureFlags.Plasma flag

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

  • Verify the feature flag conditional follows the established pattern for other gated chains
  • Confirm PlasmaMainnet identifier and flag key are correct
  • Check that the flag check placement in the chain support logic is consistent

Suggested reviewers

  • NeOMakinG
  • gomesalexandre

Poem

🐰 Plasma gates in code so bright,
Feature flags keeping chains just right,
A rabbit hopped through logic clean,
Where Plasma flows, flags unseen,
⚡ Mainnet magic, now gated tight!

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'fix: missing plasma flag filter' directly describes the main change—adding a missing feature flag filter for Plasma in PluginProvider.tsx.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch filter-plasma

📜 Recent 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.

📥 Commits

Reviewing files that changed from the base of the PR and between a834359 and f6e730a.

📒 Files selected for processing (1)
  • src/context/PluginProvider/PluginProvider.tsx (1 hunks)
🧰 Additional context used
📓 Path-based instructions (6)
**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (CLAUDE.md)

**/*.{ts,tsx,js,jsx}: Never assume a library is available - always check imports/package.json first
Prefer composition over inheritance
Write self-documenting code with clear variable and function names
Keep functions small and focused on a single responsibility
Avoid deep nesting - use early returns instead
Prefer procedural and easy to understand code
Never expose, log, or commit secrets, API keys, or credentials
Validate all inputs, especially user inputs
Handle errors gracefully with meaningful messages
Don't silently catch and ignore exceptions
Log errors appropriately for debugging
Provide fallback behavior when possible
Use appropriate data structures for the task
Never add code comments unless explicitly requested
When modifying code, do not add comments that reference previous implementations or explain what changed. Comments should only describe the current logic and functionality.
Use meaningful names for branches, variables, and functions
Always run yarn lint --fix and yarn type-check after making changes
Avoid let variable assignments - prefer const with inline IIFE switch statements or extract to functions for conditional logic

Files:

  • src/context/PluginProvider/PluginProvider.tsx
**/*.{ts,tsx}

📄 CodeRabbit inference engine (CLAUDE.md)

**/*.{ts,tsx}: Avoid useEffect where practical - use it only when necessary and following best practices
Avoid 'any' types - use specific type annotations instead
For default values with user overrides, use computed values (useMemo) instead of useEffect - pattern: userSelected ?? smartDefault ?? fallback
When function parameters are unused due to interface requirements, refactor the interface or implementation to remove them rather than prefixing with underscore
Sanitize data before displaying to prevent XSS
Memoize aggressively - wrap component variables in useMemo and callbacks in useCallback where possible
For static JSX icon elements (e.g., <TbCopy />) that don't depend on state/props, define them as constants outside the component to avoid re-renders instead of using useMemo
Account for light/dark mode using useColorModeValue hook
Account for responsive mobile designs in all UI components
When applying styles, use the existing standards and conventions of the codebase
Use Chakra UI components and conventions
All copy/text must use translation keys - never hardcode strings
Use the translation hook: useTranslate() from react-polyglot
Use useFeatureFlag('FlagName') hook to access feature flag values in components
Prefer type over interface for type definitions
Use strict typing - avoid any
Use Nominal types for domain identifiers (e.g., WalletId, AccountId)
Import types from @shapeshiftoss/caip for chain/account/asset IDs
Use useAppSelector for Redux state
Use useAppDispatch for Redux actions
Memoize expensive computations with useMemo
Memoize callbacks with useCallback

**/*.{ts,tsx}: Use Result<T, E> pattern for error handling in swappers and APIs; ALWAYS use Ok() and Err() from @sniptt/monads; AVOID throwing within swapper API implementations
ALWAYS use custom error classes from @shapeshiftoss/errors with meaningful error codes for internationalization and relevant details in error objects
ALWAYS wrap async op...

Files:

  • src/context/PluginProvider/PluginProvider.tsx
**/*.{tsx,jsx}

📄 CodeRabbit inference engine (.cursor/rules/error-handling.mdc)

**/*.{tsx,jsx}: ALWAYS wrap React components in error boundaries and provide user-friendly fallback components with error logging
ALWAYS use useErrorToast hook for displaying errors with translated error messages and handle different error types appropriately

Use PascalCase for React component names and match the component name to the file name

Files:

  • src/context/PluginProvider/PluginProvider.tsx
**/*.{js,jsx,ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/naming-conventions.mdc)

**/*.{js,jsx,ts,tsx}: Use camelCase for variables, functions, and methods with descriptive names that explain the purpose
Use verb prefixes for functions that perform actions (e.g., fetch, validate, execute, update, calculate)
Use UPPER_SNAKE_CASE for constants and configuration values with descriptive names
Use handle prefix for event handlers with descriptive names in camelCase
Use descriptive boolean variable names with is, has, can, should prefixes
Use named exports for components, functions, and utilities instead of default exports
Use descriptive import names and avoid renaming imports unless necessary
Avoid non-descriptive variable names like data, item, obj, and single-letter variable names except in loops
Avoid abbreviations in names unless they are widely understood
Avoid generic function names like fn, func, or callback

Files:

  • src/context/PluginProvider/PluginProvider.tsx
**/*.{jsx,tsx}

📄 CodeRabbit inference engine (.cursor/rules/react-best-practices.mdc)

**/*.{jsx,tsx}: ALWAYS use useMemo for expensive computations, object/array creations, and filtered data
ALWAYS use useMemo for derived values and computed properties
ALWAYS use useMemo for conditional values and simple transformations
ALWAYS use useCallback for event handlers and functions passed as props
ALWAYS use useCallback for any function that could be passed as a prop or dependency
ALWAYS include all dependencies in useEffect, useMemo, useCallback dependency arrays
NEVER use // eslint-disable-next-line react-hooks/exhaustive-deps unless absolutely necessary, and ALWAYS explain why dependencies are excluded if using eslint disable
ALWAYS use named exports for components; NEVER use default exports for components
KEEP component files under 200 lines when possible; BREAK DOWN large components into smaller, reusable pieces
EXTRACT complex logic into custom hooks
ALWAYS wrap components in error boundaries for production
ALWAYS handle async errors properly in async operations
ALWAYS provide user-friendly error messages in error handling
ALWAYS use virtualization for lists with 100+ items
ALWAYS implement proper key props for list items
ALWAYS lazy load heavy components using React.lazy for code splitting
ALWAYS use Suspense wrapper for lazy loaded components
USE local state for component-level state; LIFT state up when needed across multiple components; USE Context for avoiding prop drilling; USE Redux only for global state shared across multiple places
Wrap components receiving props with memo for performance optimization

Files:

  • src/context/PluginProvider/PluginProvider.tsx
**/*.tsx

📄 CodeRabbit inference engine (.cursor/rules/react-best-practices.mdc)

Ensure TypeScript types are explicit and proper; avoid use of any type

Files:

  • src/context/PluginProvider/PluginProvider.tsx
🧠 Learnings (4)
📓 Common learnings
Learnt from: NeOMakinG
Repo: shapeshift/web PR: 10231
File: src/components/AssetSearch/components/AssetList.tsx:2-2
Timestamp: 2025-08-08T15:00:49.887Z
Learning: Project shapeshift/web: NeOMakinG prefers avoiding minor a11y/UI nitpicks (e.g., adding aria-hidden to decorative icons in empty states like src/components/AssetSearch/components/AssetList.tsx) within feature PRs; defer such suggestions to a follow-up instead of blocking the PR.
Learnt from: gomesalexandre
Repo: shapeshift/web PR: 11170
File: patches/@shapeshiftoss+bitcoinjs-lib+7.0.0-shapeshift.0.patch:9-19
Timestamp: 2025-11-25T21:43:10.838Z
Learning: In shapeshift/web, gomesalexandre will not expand PR scope to fix latent bugs in unused API surface (like bitcoinjs-lib patch validation methods) when comprehensive testing proves the actual used code paths work correctly, preferring to avoid costly hdwallet/web verdaccio publish cycles and full regression testing for conceptual issues with zero runtime impact.
📚 Learning: 2025-11-24T21:20:04.979Z
Learnt from: CR
Repo: shapeshift/web PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T21:20:04.979Z
Learning: To add a new feature flag: (1) Add to `FeatureFlags` type in `src/state/slices/preferencesSlice/preferencesSlice.ts`, (2) Add environment variable validation in `src/config.ts`, (3) Add to initial state in `preferencesSlice.ts`, (4) Add to test mock in `src/test/mocks/store.ts`, (5) Set appropriate values in `.env`, `.env.development`, and `.env.production`

Applied to files:

  • src/context/PluginProvider/PluginProvider.tsx
📚 Learning: 2025-11-24T21:20:04.979Z
Learnt from: CR
Repo: shapeshift/web PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T21:20:04.979Z
Learning: Applies to **/*.{ts,tsx} : Use `useFeatureFlag('FlagName')` hook to access feature flag values in components

Applied to files:

  • src/context/PluginProvider/PluginProvider.tsx
📚 Learning: 2025-10-23T14:27:19.073Z
Learnt from: gomesalexandre
Repo: shapeshift/web PR: 10857
File: src/plugins/walletConnectToDapps/eventsManager/useWalletConnectEventsHandler.ts:101-104
Timestamp: 2025-10-23T14:27:19.073Z
Learning: In WalletConnect wallet_switchEthereumChain and wallet_addEthereumChain requests, the chainId parameter is always present as per the protocol spec. Type guards checking for missing chainId in these handlers (like `if (!evmNetworkIdHex) return`) are solely for TypeScript compiler satisfaction, not real runtime edge cases.

Applied to files:

  • src/context/PluginProvider/PluginProvider.tsx
⏰ 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). (2)
  • GitHub Check: Call / Static
  • GitHub Check: Cursor Bugbot
🔇 Additional comments (1)
src/context/PluginProvider/PluginProvider.tsx (1)

120-120: Implementation is correct and follows established patterns.

The code at line 120 correctly filters the Plasma chain based on its feature flag. The implementation:

  • Uses the correct feature flag property (featureFlags.Plasma)
  • References the correct chain ID constant (KnownChainIds.PlasmaMainnet = eip155:9745)
  • Follows the exact pattern as other feature-flagged chains
  • Has all supporting infrastructure in place (type definition, environment variables, test mocks)

The pattern is consistent with Monad, Mayachain, and other feature-flagged chains in the same filter.


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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@0xApotheosis 0xApotheosis merged commit 811f48a into develop Dec 11, 2025
5 checks passed
@0xApotheosis 0xApotheosis deleted the filter-plasma branch December 11, 2025 02:54
0xApotheosis added a commit that referenced this pull request Dec 11, 2025
@coderabbitai coderabbitai bot mentioned this pull request Dec 11, 2025
1 task
@coderabbitai coderabbitai bot mentioned this pull request Jan 17, 2026
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant