Skip to content

caLookupProvider (if not spartan-intel)#23

Open
odilitime wants to merge 3 commits into1.xfrom
odi-provider
Open

caLookupProvider (if not spartan-intel)#23
odilitime wants to merge 3 commits into1.xfrom
odi-provider

Conversation

@odilitime
Copy link
Member

@odilitime odilitime commented Oct 31, 2025

Note

Introduces a Solana CA lookup provider to fetch on-chain token details from message addresses and registers it only when spartan-intel isn't loaded, with comprehensive tests.

  • Providers:
    • Add src/providers/ca-lookup.ts (SOLANA_CA_SYMBOL_LOOKUP) to extract addresses from messages and fetch on-chain token data (symbol, type, decimals, supply), filtering non-token addresses and handling errors.
  • Plugin Init (src/index.ts):
    • Conditionally register caLookupProvider only if spartan-intel plugin is absent; minor logging/formatting tweaks.
  • Tests:
    • Add __tests__/providers/ca-lookup.test.ts covering no addresses, single/multiple addresses, missing service, non-token filtering, error handling, and provider metadata.

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

Summary by CodeRabbit

  • New Features

    • Added a Solana CA symbol lookup that retrieves token symbol, type, decimals, and supply for detected on-chain addresses.
    • Provider registration now conditionally skips adding the lookup when an overlapping plugin is present to avoid duplicate registration.
  • Tests

    • Added comprehensive tests validating address extraction, token filtering, error paths, and provider metadata.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Oct 31, 2025

Walkthrough

Adds a new dynamic Solana CA symbol/token lookup provider and comprehensive tests; provider extracts Solana addresses from messages, queries on-chain metadata (symbol, type, decimals, supply), filters token types, formats results, and is registered only when the spartan-intel plugin is absent.

Changes

Cohort / File(s) Change Summary
New CA Lookup Provider Implementation
src/providers/ca-lookup.ts
Adds caLookupProvider export: detects Solana addresses in message text, queries Solana service for symbol, type, decimals and supply (parallel fetch), filters for token-type addresses, aggregates token metadata, builds human-readable text and data payloads, and handles missing service and RPC errors.
Provider Registration Logic
src/index.ts
Conditionally registers caLookupProvider only when the spartan-intel plugin is not loaded; logs when skipped and adjusts error log formatting for INTEL_CHAIN registration.
Comprehensive Test Suite
__tests__/providers/ca-lookup.test.ts
Adds tests covering: no addresses found, single/multiple address extraction, service unavailable, filtering non-token addresses (wallet), RPC error handling, and provider metadata assertions; extensively mocks runtime, state, and Solana service interactions.

Sequence Diagram(s)

sequenceDiagram
    participant Runtime
    participant caLookupProvider
    participant SolanaService
    participant OnChainRPC as On-Chain RPC

    Runtime->>caLookupProvider: get(runtime, message, state)
    caLookupProvider->>SolanaService: getService(SOLANA_SERVICE_NAME)
    alt Service Available
        SolanaService-->>caLookupProvider: service
        caLookupProvider->>SolanaService: detectPubkeysFromString(text)
        SolanaService-->>caLookupProvider: addresses[]
        alt Addresses Found
            par Parallel metadata fetch
                caLookupProvider->>OnChainRPC: getTokenSymbol(address)
                caLookupProvider->>OnChainRPC: getTokenType(address)
                caLookupProvider->>OnChainRPC: getDecimals(address)
                caLookupProvider->>OnChainRPC: getSupply(address)
            and Filter & Aggregate
                OnChainRPC-->>caLookupProvider: metadata
                caLookupProvider->>caLookupProvider: filter token-type entries
                caLookupProvider->>caLookupProvider: assemble data, values, text
            end
            caLookupProvider-->>Runtime: { data, values, text }
        else No Addresses Found
            caLookupProvider-->>Runtime: false
        end
    else Service Unavailable
        SolanaService-->>caLookupProvider: null
        caLookupProvider-->>Runtime: false
    end
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

  • Pay extra attention to:
    • Parallel fetching and Promise error handling in src/providers/ca-lookup.ts.
    • Correct filtering logic that distinguishes token vs wallet address types.
    • Mock setups and assertions in __tests__/providers/ca-lookup.test.ts matching provider behavior.
    • Conditional registration and log messages in src/index.ts.

Poem

🐰 I hopped through chains to fetch each name,
Symbols, supplies — I played the game.
I filtered wallets, found tokens bright,
Brought data home beneath moonlight.
Hop, hop — CA lookup done — what a delight!

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check ✅ Passed The title "caLookupProvider (if not spartan-intel)" accurately captures the primary objective of the pull request. It directly references the new provider being introduced (caLookupProvider) and includes the important conditional registration logic (only loaded when spartan-intel is not present). The title is concise, specific, and avoids vague terms or noise. A team member scanning the commit history would clearly understand that a new Solana CA lookup provider is being added with conditional registration behavior. The title aligns well with the substantial changes across three files: the new provider implementation, conditional registration in the main index file, and comprehensive test coverage.
✨ 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 odi-provider

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to data retention organization setting

📥 Commits

Reviewing files that changed from the base of the PR and between cabdbba and 8be9e87.

📒 Files selected for processing (1)
  • src/index.ts (3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • src/index.ts

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.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to data retention organization setting

📥 Commits

Reviewing files that changed from the base of the PR and between 5f9d3cf and cabdbba.

📒 Files selected for processing (3)
  • __tests__/providers/ca-lookup.test.ts (1 hunks)
  • src/index.ts (3 hunks)
  • src/providers/ca-lookup.ts (1 hunks)
🔇 Additional comments (18)
src/index.ts (3)

18-18: LGTM!

The import is correctly placed with other provider imports.


53-53: LGTM!

Formatting improvement for consistency.


63-63: LGTM!

Using structured logging with the error object is a best practice that improves debuggability.

src/providers/ca-lookup.ts (7)

1-14: LGTM!

The documentation clearly explains the provider's purpose and behavior. Good practice to note that no LLM calls are made.


15-26: LGTM!

The provider metadata is well-defined and the service availability check with early return follows best practices.


28-37: LGTM!

Safe handling of optional message content with appropriate early return when no addresses are found.


39-61: LGTM!

Efficient parallel data fetching with appropriate error handling. Good practice to handle supply fetch errors separately since it may fail independently.


72-92: Verify the type filtering logic is intentional.

Line 77 uses type === 'Token' || type.includes('Token') which will match any type containing "Token" (e.g., "Token Account", "Token-2022", "TokenProgram"). Based on the test at line 137 in ca-lookup.test.ts which expects "Wallet" to be filtered out, this appears intentional, but please confirm this matches the desired behavior for all token-related account types.


94-97: LGTM!

Appropriate handling for the case where addresses are detected but none are tokens.


99-125: LGTM!

Clean output formatting with both structured data and human-readable text. The separation of lookupCount (total addresses) and resolvedCount (valid tokens) provides useful insight into filtering results.

__tests__/providers/ca-lookup.test.ts (8)

1-33: LGTM!

Comprehensive test setup with appropriate mocks and defaults. The mock structure accurately reflects the runtime interfaces.


35-49: LGTM!

Test properly verifies the early return behavior when no addresses are detected.


51-76: LGTM!

Comprehensive test case that validates the complete flow from address detection to formatted output. Good coverage of both data structure and text formatting.


78-109: LGTM!

Well-structured test for multiple addresses that validates both the count and content of results.


111-122: LGTM!

Good coverage of the error path when the Solana service is unavailable, including verification of logging behavior.


124-155: LGTM!

Excellent test coverage of the filtering logic. The verification of both lookupCount (2) and resolvedCount (1) demonstrates that the provider correctly distinguishes between detected addresses and valid tokens.


157-177: LGTM!

Good coverage of error handling when RPC calls fail. Verifies both the return value and error logging behavior.


179-183: LGTM!

Simple but essential test that validates the provider's metadata configuration.

symbol: symbolMap[ca] || null,
type,
decimals: decimals[i] ?? -1,
};
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: Bug

The caLookupProvider accesses token decimals by array index, while other token details use the contract address as a key. This assumes the getDecimals service method preserves the input address order, which could lead to incorrect decimal assignments if not guaranteed.

Fix in Cursor Fix in Web

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