Skip to content

Conversation

@vignesha22
Copy link
Contributor

@vignesha22 vignesha22 commented Nov 14, 2025

Description

  • Fixed the initialisation of intent sdk for pillar wallet

How Has This Been Tested?

  • Tested locally

Screenshots (if appropriate):

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Summary by CodeRabbit

  • Refactor

    • Simplified module installation flow to assume modules are available, reducing installation delays.
    • Updated wallet connection to a new provider pathway for more consistent connections.
  • New Features

    • Added a client-side in-browser debug console to aid troubleshooting.
  • Chores

    • Enabled additional runtime diagnostics to improve troubleshooting and support.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Nov 14, 2025

Walkthrough

Adds eruda and initializes a client-side debug console, injects extensive runtime logging across Pulse buy/home components, migrates Intent SDK initialization to Transaction Kit (hard-coding pulse node URL), and replaces module-install flow with a no-op that marks modules as installed.

Changes

Cohort / File(s) Summary
Eruda Debug Console Setup
package.json, src/main.tsx
Added eruda@3.4.3 to dependencies/devDependencies and initialized Eruda in src/main.tsx behind a window/client guard.
Component Debug Logging
src/apps/pulse/components/App/HomeScreen.tsx, src/apps/pulse/components/Buy/Buy.tsx, src/apps/pulse/components/Buy/BuyButton.tsx
Inserted extensive console.log tracing across HomeScreen (preview state, handleRefresh, polling), Buy (handleBuySubmit, USD handling, refresh/expressIntent flows, timers/effects), and BuyButton (disabled-state checks, logs, wrapper onClick). Control flow and public APIs remain unchanged.
Intent SDK Initialization → Transaction Kit
src/apps/pulse/hooks/useIntentSdk.ts
Replaced prior Privy/Wagmi/WalletConnect branches with a Transaction Kit (useTransactionKit) initialization path using kit.getEtherspotProvider() and wallet client retrieval; added init/error logs and hard-coded pulse node URL to https://pulse.etherspot.io.
Module Installation Simplification
src/apps/pulse/hooks/useModularSdk.ts
Changed areModulesInstalled initial state to true and replaced the prior install/receipt-waiting logic with a no-op that sets areModulesInstalled to true (installation code commented out).

Sequence Diagram(s)

sequenceDiagram
    participant App as App / Components
    participant useIntentSdk as useIntentSdk Hook
    participant TxKit as Transaction Kit
    participant Etherspot as Etherspot Provider
    participant Intent as Intent SDK

    App->>useIntentSdk: mount / useEffect
    useIntentSdk->>TxKit: useTransactionKit()
    TxKit-->>useIntentSdk: kit, accountAddress

    alt kit available
        useIntentSdk->>Etherspot: kit.getEtherspotProvider()
        Etherspot-->>useIntentSdk: walletProvider
        useIntentSdk->>useIntentSdk: log progress
        useIntentSdk->>Intent: initialize (provider/client, hard-coded node URL)
        Intent-->>useIntentSdk: intentSdk instance
        useIntentSdk->>App: intentSdk ready (logged)
    else kit unavailable
        useIntentSdk->>useIntentSdk: log error / early return
        useIntentSdk-->>App: intentSdk not initialized
    end
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Areas needing extra attention:

  • src/apps/pulse/hooks/useIntentSdk.ts — verify Transaction Kit integration, wallet client retrieval, and hard-coded pulse URL intent.
  • src/apps/pulse/hooks/useModularSdk.ts — confirm intentional disabling of module installation and downstream effects.
  • src/apps/pulse/components/Buy/BuyButton.tsx — changed disabled calculation and onClick wrapper; ensure UX/edge cases.
  • Widespread console logging — review for sensitive data and production removal.

Possibly related PRs

Suggested reviewers

  • IAmKio
  • nikhilkumar1612

Poem

🐰 A tiny rabbit taps the keys tonight,

Logs a trail of breadcrumbs, bold and bright,
Intent finds a new, straight path to roam,
Modules dream and claim their restful home,
Hoppy debugging — carrots all in sight! 🥕

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)
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.
Title check ❓ Inconclusive The title 'PillarWallet Testing' is vague and generic, providing minimal clarity about the specific changes made in the pull request. Replace with a more specific title reflecting the main change, such as 'Fix Intent SDK initialization for Pillar Wallet' or 'Migrate Intent SDK to Transaction Kit-based approach'.
✅ Passed checks (1 passed)
Check name Status Explanation
Description check ✅ Passed The PR description covers the required sections (Description, How Has This Been Tested, Types of changes) with basic information about the intent SDK fix and local testing.
✨ 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 fix/7702-Testing

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ee4ba50 and 467a201.

📒 Files selected for processing (1)
  • src/apps/pulse/hooks/useIntentSdk.ts (3 hunks)
🧰 Additional context used
🧠 Learnings (3)
📚 Learning: 2025-08-12T07:42:24.656Z
Learnt from: IAmKio
Repo: pillarwallet/x PR: 351
File: src/apps/pulse/utils/intent.ts:44-53
Timestamp: 2025-08-12T07:42:24.656Z
Learning: In the Pulse app's intent utilities (src/apps/pulse/utils/intent.ts), the team has chosen to use floating-point arithmetic for token amount calculations despite potential precision issues, accepting JavaScript's decimal place limitations as a valid trade-off for their use case.

Applied to files:

  • src/apps/pulse/hooks/useIntentSdk.ts
📚 Learning: 2025-08-20T09:14:16.888Z
Learnt from: RanaBug
Repo: pillarwallet/x PR: 374
File: src/apps/pillarx-app/index.tsx:12-12
Timestamp: 2025-08-20T09:14:16.888Z
Learning: In this codebase, Transaction Kit providers are set up at the container level (src/containers/Authorized.tsx), not at individual app component levels. App components like src/apps/pillarx-app/index.tsx are children that consume the context through the provider tree.

Applied to files:

  • src/apps/pulse/hooks/useIntentSdk.ts
📚 Learning: 2025-11-04T14:34:00.373Z
Learnt from: RanaBug
Repo: pillarwallet/x PR: 445
File: src/containers/Authorized.tsx:63-77
Timestamp: 2025-11-04T14:34:00.373Z
Learning: In src/containers/Authorized.tsx, the tempKit useEffect intentionally excludes chainId from its dependency array because the kit is used by useWalletModeVerification to check wallet mode across all supported chains, regardless of the currently selected chainId. The chainId parameter is only used for initial kit configuration and does not affect the multi-chain verification results.

Applied to files:

  • src/apps/pulse/hooks/useIntentSdk.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: lint
  • GitHub Check: unit-tests
  • GitHub Check: build
🔇 Additional comments (3)
src/apps/pulse/hooks/useIntentSdk.ts (3)

92-122: LGTM! Transaction Kit initialization is properly guarded.

The initialization flow correctly guards against kit, walletProvider, and walletClient being unavailable, with early returns preventing null-dereference errors. The addition of kit to the dependency array ensures the effect re-runs when Transaction Kit becomes available.


116-116: Verify type compatibility between Transaction Kit and Intent SDK.

The as any assertion at line 116 bypasses type checking. While this pattern is consistent across all IntentSdk initialization code paths in the file (lines 46, 82, and 116—with only line 116 active), the underlying type compatibility cannot be verified from the codebase alone since both @etherspot/intent-sdk (v1.0.0-alpha.10) and @etherspot/transaction-kit (v2.1.3) are external dependencies. Given the alpha version status of intent-sdk, the types may be unstable.

Check whether the return type of walletProvider.getWalletClient() from Transaction Kit can be made directly compatible with IntentSdk's constructor parameter, eliminating the need for the as any cast.


32-32: Verify the Pulse node URL against Intent SDK requirements.

The hard-coded URL https://pulse.etherspot.io differs from official Etherspot RPC endpoint documentation, which shows https://rpc.etherspot.io/v1/369?api-key=[YOUR_API_KEY]. Additionally, elsewhere in the codebase (src/services/userOpStatus.ts, src/hooks/useDeployWallet.tsx), the RPC endpoint is configured as https://rpc.etherspot.io/v2/{chainId}?api-key={apiKey}.

Please confirm:

  1. Whether pulse.etherspot.io is the correct endpoint specifically required by the Intent SDK's pulseNodeUrl parameter
  2. Whether the chain ID and API key should be included in this URL, or if the Intent SDK handles them separately

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.

@github-actions github-actions bot temporarily deployed to Preview (fix/7702-Testing) November 14, 2025 10:45 Inactive
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: 2

🧹 Nitpick comments (8)
package.json (1)

120-120: Confirm eruda placement vs deploy pipeline

eruda is imported at runtime in src/main.tsx but currently only listed under devDependencies. If your build/deploy pipeline installs only production deps (e.g. npm ci --only=prod), this can break builds due to a missing module. Consider either:

  • Moving eruda to "dependencies" (and gating its usage by env), or
  • Ensuring your build step always installs devDependencies in this app repo.
src/main.tsx (1)

6-17: Gate Eruda debug console to non‑production / opt‑in environments

Right now eruda.init() runs in every browser environment, so the debug console ships to users as well. To avoid impacting production UX and to keep control over when debugging is enabled, consider gating this:

-import eruda from 'eruda';
+import eruda from 'eruda';

 // Initialize Eruda debug console for mobile debugging
-if (typeof window !== 'undefined') {
-  eruda.init();
-  console.log('Eruda debug console initialized - look for floating button on screen');
-}
+if (
+  typeof window !== 'undefined' &&
+  (import.meta.env.DEV || import.meta.env.VITE_ENABLE_ERUDA === 'true')
+) {
+  eruda.init();
+  console.log(
+    'Eruda debug console initialized - look for floating button on screen'
+  );
+}

This keeps Eruda available for local/staging debugging without forcing it on every production user.

src/apps/pulse/hooks/useIntentSdk.ts (2)

109-112: Avoid using alert() inside a shared hook

Using alert('Failed to initialize Intent SDK. Please try again.' + err); inside a hook is intrusive and can fire multiple times (e.g. React 18 StrictMode double effect invocation) or in background flows. You already expose an error state, which is better for surfacing issues via UI.

Consider removing the alert and relying solely on state and console logging:

-      } catch (err) {
-        alert('Failed to initialize Intent SDK. Please try again.' + err);
-        console.error('Failed to initialize Intent SDK:', err);
-        setError('Failed to initialize Intent SDK. Please try again.');
-      }
+      } catch (err) {
+        console.error('Failed to initialize Intent SDK:', err);
+        setError('Failed to initialize Intent SDK. Please try again.');
+      }

12-21: Large blocks of commented‑out Privy/WalletConnect logic add noise

A lot of the previous Privy / WalletConnect initialization paths are now commented out. Unless you expect to re‑enable them soon, consider either:

  • Removing them entirely (git history will preserve the old implementation), or
  • Wrapping them in a clearly marked fallback block with a TODO explaining under what conditions they should be restored.

This will keep the hook focused on the Transaction Kit path and reduce cognitive load for future readers.

Also applies to: 36-52, 53-89, 118-122

src/apps/pulse/components/Buy/Buy.tsx (1)

183-202: Gate verbose Buy‑flow logging behind a debug flag

The new logs in handleBuySubmit, the debounced USD effect, and refreshBuyIntent (including full intent/response dumps) are great for diagnosing issues, but they’re fairly chatty and include wallet‑related amounts and responses. For ongoing development this is fine; for staging/production it may be noisy.

Consider wrapping these logs in a simple runtime guard so they can be enabled only when needed, e.g.:

const isPulseDebugEnabled =
  import.meta.env.DEV || import.meta.env.VITE_PULSE_DEBUG === 'true';

if (isPulseDebugEnabled) {
  console.log('=== BUY: refreshBuyIntent called ===');
  console.log('intentSdk:', intentSdk);
  // ...
}

You can reuse the same flag across Buy, HomeScreen, and related hooks to keep logging consistent and easy to toggle.

Also applies to: 221-234, 267-304, 308-315, 350-371

src/apps/pulse/components/App/HomeScreen.tsx (1)

105-108: HomeScreen debug logging should also be gated

The new logs around previewBuy changes, handleRefresh, and renderPreview are useful for tracing flows but will add a lot of noise in the console over time (especially with the 15‑second auto‑refreshes).

Like in Buy.tsx, consider centralizing this behind a flag:

const isPulseDebugEnabled =
  import.meta.env.DEV || import.meta.env.VITE_PULSE_DEBUG === 'true';

useEffect(() => {
  if (isPulseDebugEnabled) {
    console.log('=== HOMESCREEN: previewBuy state changed to:', previewBuy);
  }
}, [previewBuy]);

and similarly wrap the other console.log calls so you can turn them on/off per environment without code changes.

Also applies to: 293-358, 911-916

src/apps/pulse/hooks/useModularSdk.ts (1)

31-31: areModulesInstalled is now effectively hard‑wired to true, making the module status check dead code

With the state initialized as:

const [areModulesInstalled, setAreModulesInstalled] = useState<boolean>(true);

and your check effect guarded by if (!areModulesInstalled && modularSdk && payingTokens.length > 0), there is currently no path that sets areModulesInstalled to false from outside that effect. As a result:

  • The useEffect at lines 124–153 never runs for a fresh mount (the condition is false on first render).
  • modularSdk.pulse.isPulseModulesInstalled(...) is never called.
  • isFetching is never toggled by the module‑status flow.
  • Callers (e.g. BuyButton expecting a false state to show “Enable Trading…” and trigger install flows) will never see areModulesInstalled === false.

If the intent is to temporarily bypass module detection/installation and always treat modules as installed, it would be clearer to either:

  • Remove or explicitly comment out the isPulseModulesInstalled effect, and document that areModulesInstalled is forced to true as a temporary workaround; or
  • Reintroduce a tri‑state/“unknown” value (e.g. boolean | undefined) and drive the effect off “unknown”, so the status check still runs and can set the flag to true/false.

If, instead, you still rely on the “modules need installation” UI path and backend checks, this current shape is likely a functional regression and you’ll want to restore a path where areModulesInstalled can be false and let the effect fire at least once.

Also applies to: 124-153, 155-181

src/apps/pulse/components/Buy/BuyButton.tsx (1)

108-130: isDisabled() side effects (logging) are evaluated 3× per render, and the “modules need installation” branch may never fire

Two points here:

  1. Multiple calls per render with logging

isDisabled() is invoked for:

  • disabled={isDisabled()}
  • backgroundColor: isDisabled() ? …
  • The last argument to getButtonText(..., isDisabled())

Each call runs the same logic and emits logs (Button disabled: …, Final disabled state: …). That’s harmless functionally but makes logs noisy and less useful when debugging.

A small refactor would make this cleaner:

-  const isDisabled = () => {
+  const isDisabled = () => {
     if (isInstalling || isFetching) {
       console.log('Button disabled: installing or fetching');
       return true;
     }
     if (notEnoughLiquidity) {
       console.log('Button disabled: not enough liquidity');
       return true;
     }
     if (!areModulesInstalled && payingTokens.length > 0) {
       console.log('Button enabled: modules need installation');
       return false;
     }

     const disabled =
       isLoading ||
       !token ||
       !(parseFloat(usdAmount) > 0) ||
       !expressIntentResponse;

     console.log('Final disabled state:', disabled);
     return disabled;
   };
+
+  const disabled = isDisabled();

Then in JSX:

-      disabled={isDisabled()}
+      disabled={disabled}
       style={{
-        backgroundColor: isDisabled() ? '#29292F' : '#8A77FF',
-        color: isDisabled() ? 'grey' : '#FFFFFF',
+        backgroundColor: disabled ? '#29292F' : '#8A77FF',
+        color: disabled ? 'grey' : '#FFFFFF',
       }}
...
-        isDisabled()
+        disabled

This keeps logs, but evaluates them once per render.

  1. “Modules need installation” branch vs. current useModularSdk behavior

The branch:

if (!areModulesInstalled && payingTokens.length > 0) {
  console.log('Button enabled: modules need installation');
  return false;
}

assumes areModulesInstalled can be false. However, the updated useModularSdk hook now initializes areModulesInstalled to true and (in its current form) never sets it to false, which means this branch — and the corresponding “Enable Trading on …” UI — may never be hit.

If you intend to support the “install modules” path, you probably want useModularSdk to surface a real false value when modules are missing; otherwise, consider simplifying this branch and the related button text to align with the new assumption that modules are always treated as installed.

Also applies to: 135-137

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3ededb3 and 602565a.

⛔ Files ignored due to path filters (1)
  • package-lock.json is excluded by !**/package-lock.json
📒 Files selected for processing (7)
  • package.json (1 hunks)
  • src/apps/pulse/components/App/HomeScreen.tsx (7 hunks)
  • src/apps/pulse/components/Buy/Buy.tsx (6 hunks)
  • src/apps/pulse/components/Buy/BuyButton.tsx (1 hunks)
  • src/apps/pulse/hooks/useIntentSdk.ts (3 hunks)
  • src/apps/pulse/hooks/useModularSdk.ts (2 hunks)
  • src/main.tsx (1 hunks)
🧰 Additional context used
🧠 Learnings (4)
📚 Learning: 2025-11-04T14:34:00.373Z
Learnt from: RanaBug
Repo: pillarwallet/x PR: 445
File: src/containers/Authorized.tsx:63-77
Timestamp: 2025-11-04T14:34:00.373Z
Learning: In src/containers/Authorized.tsx, the tempKit useEffect intentionally excludes chainId from its dependency array because the kit is used by useWalletModeVerification to check wallet mode across all supported chains, regardless of the currently selected chainId. The chainId parameter is only used for initial kit configuration and does not affect the multi-chain verification results.

Applied to files:

  • src/apps/pulse/hooks/useModularSdk.ts
  • src/apps/pulse/hooks/useIntentSdk.ts
📚 Learning: 2025-09-09T12:40:15.629Z
Learnt from: RanaBug
Repo: pillarwallet/x PR: 391
File: src/apps/pulse/components/Sell/Sell.tsx:113-130
Timestamp: 2025-09-09T12:40:15.629Z
Learning: In the Pulse app Sell component, when a user changes/switches tokens, the input amount automatically resets to 0, which means liquidity validation state doesn't become stale when tokens change.

Applied to files:

  • src/apps/pulse/components/App/HomeScreen.tsx
  • src/apps/pulse/components/Buy/Buy.tsx
📚 Learning: 2025-08-12T07:42:24.656Z
Learnt from: IAmKio
Repo: pillarwallet/x PR: 351
File: src/apps/pulse/utils/intent.ts:44-53
Timestamp: 2025-08-12T07:42:24.656Z
Learning: In the Pulse app's intent utilities (src/apps/pulse/utils/intent.ts), the team has chosen to use floating-point arithmetic for token amount calculations despite potential precision issues, accepting JavaScript's decimal place limitations as a valid trade-off for their use case.

Applied to files:

  • src/apps/pulse/hooks/useIntentSdk.ts
  • src/apps/pulse/components/Buy/Buy.tsx
📚 Learning: 2025-08-20T09:14:16.888Z
Learnt from: RanaBug
Repo: pillarwallet/x PR: 374
File: src/apps/pillarx-app/index.tsx:12-12
Timestamp: 2025-08-20T09:14:16.888Z
Learning: In this codebase, Transaction Kit providers are set up at the container level (src/containers/Authorized.tsx), not at individual app component levels. App components like src/apps/pillarx-app/index.tsx are children that consume the context through the provider tree.

Applied to files:

  • src/apps/pulse/hooks/useIntentSdk.ts
🧬 Code graph analysis (1)
src/apps/pulse/components/Buy/Buy.tsx (1)
src/apps/pulse/utils/intent.ts (1)
  • getDispensableAssets (22-88)
⏰ 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: lint
  • GitHub Check: unit-tests

Comment on lines 686 to 691
try {
if (isBuyTransaction) {
if (!intentSdk) {
console.error('Intent SDK not initialized');
return;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

Prevent endless polling loop when Intent SDK is not initialized

In the buy‑polling branch:

if (isBuyTransaction) {
  if (!intentSdk) {
    console.error('Intent SDK not initialized');
    return;
  }
  // ...
}

If intentSdk is null, this logs an error and returns, but:

  • isPollingActive / isBackgroundPolling are not changed, and
  • The outer setInterval(pollStatus, 2000) continues to run,

so you’ll keep logging every 2s and the transaction status never moves to a final state.

Consider either preventing polling from starting when intentSdk is missing, or failing fast here by stopping polling and surfacing an error, e.g.:

-        if (isBuyTransaction) {
-          if (!intentSdk) {
-            console.error('Intent SDK not initialized');
-            return;
-          }
+        if (isBuyTransaction) {
+          if (!intentSdk) {
+            console.error('Intent SDK not initialized – stopping polling');
+            setIsPollingActive(false);
+            setIsBackgroundPolling(false);
+            setCurrentTransactionStatus('Transaction Failed');
+            setErrorDetails('Unable to fetch buy transaction status.');
+            return;
+          }

You could also guard the whole polling effect so it never starts a buy‑poll interval until intentSdk is truthy.



🏁 Script executed:

#!/bin/bash
# Find the polling effect in HomeScreen.tsx and the setInterval call
rg -n -A 30 "setInterval.*pollStatus" src/apps/pulse/components/App/HomeScreen.tsx

Length of output: 833


🏁 Script executed:

#!/bin/bash
# Look for the polling effect definition and dependencies around lines 686-691
rg -n -B 20 -A 20 "if \(!intentSdk\)" src/apps/pulse/components/App/HomeScreen.tsx | head -80

Length of output: 1618


🏁 Script executed:

#!/bin/bash
# Find where isPollingActive and isBackgroundPolling are set/used in the polling context
rg -n "setIsPollingActive|setIsBackgroundPolling" src/apps/pulse/components/App/HomeScreen.tsx

Length of output: 832


🏁 Script executed:

#!/bin/bash
# Look for the overall polling effect structure
ast-grep --pattern $'useEffect(() => {
  $$$
  setInterval($$$)
  $$$
}, $_)'  src/apps/pulse/components/App/HomeScreen.tsx

Length of output: 0


Prevent endless polling loop when Intent SDK is not initialized

In the buy‑polling effect (line 671):

The effect's early return guard at line 676 does not check for intentSdk:

if (!userOpHash || !chainId || (!isPollingActive && !isBackgroundPolling)) {
  return undefined;
}

If intentSdk is null, this does not prevent the polling interval from starting at line 846. Once running, pollStatus will be called every 2 seconds, hit the check at lines 688–691, log an error, and return—but the interval continues indefinitely.

The suggested fix is valid: either add !intentSdk to the early return condition, or stop polling inside pollStatus when intentSdk is missing:

      try {
        if (isBuyTransaction) {
          if (!intentSdk) {
            console.error('Intent SDK not initialized – stopping polling');
            setIsPollingActive(false);
            setIsBackgroundPolling(false);
            setCurrentTransactionStatus('Transaction Failed');
            setErrorDetails('Unable to fetch buy transaction status.');
            return;
          }

Alternatively, add !intentSdk to the effect's early return guard at line 676 to prevent the interval from starting at all.

🤖 Prompt for AI Agents
In src/apps/pulse/components/App/HomeScreen.tsx around lines 686 to 691, the
buy-polling effect can start an interval even when intentSdk is null, causing
endless polling that only logs an error; modify the effect's early return
condition (the guard a few lines above) to include a check for !intentSdk so the
interval never starts when intentSdk is missing, or alternatively add logic at
the start of pollStatus to clear/stop the interval when intentSdk is null —
implement the first option by adding !intentSdk to the existing OR condition so
the effect returns undefined and does not set the polling interval.

@cloudflare-workers-and-pages
Copy link

cloudflare-workers-and-pages bot commented Nov 14, 2025

Deploying x with  Cloudflare Pages  Cloudflare Pages

Latest commit: 467a201
Status: ✅  Deploy successful!
Preview URL: https://8394b256.x-e62.pages.dev
Branch Preview URL: https://fix-7702-testing.x-e62.pages.dev

View logs

@github-actions github-actions bot temporarily deployed to Preview (fix/7702-Testing) November 14, 2025 10:52 Inactive
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: 3

♻️ Duplicate comments (1)
src/apps/pulse/hooks/useIntentSdk.ts (1)

92-109: Well done fixing the critical null-dereference issue!

The guards for kit, walletProvider, and walletClient now prevent the runtime crash flagged in the previous review. The early returns ensure initialization only proceeds when all required objects are available.

🧹 Nitpick comments (1)
src/apps/pulse/hooks/useIntentSdk.ts (1)

36-125: Consider reducing verbose console logging for production.

The initialization flow includes 9 console.log statements (lines 36, 93, 100, 107, 111-117, 121-125). While helpful for debugging during development, this level of logging may be excessive for production. Consider using a debug flag or environment variable to conditionally enable verbose logging, or replace some logs with a single summary log on success/failure.

Example approach using environment-based debug flag:

+ const DEBUG = import.meta.env.MODE === 'development';
+
  try {
-   console.log('Attempting to initialize Intent SDK');
+   if (DEBUG) console.log('Attempting to initialize Intent SDK');
    
    if (!kit) {
-     console.log('Transaction Kit not yet available');
+     if (DEBUG) console.log('Transaction Kit not yet available');
      return;
    }
    
    // ... similar changes for other debug logs
    
    const sdk = new IntentSdk(walletClient as any, options);
    setIntentSdk(sdk);
-   console.log('Initialized Intent SDK via Transaction Kit wallet provider');
+   console.log('Intent SDK initialized successfully'); // Keep one summary log
    setError(null);
-   console.log('Intent SDK initialization attempt finished');
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 602565a and ee4ba50.

⛔ Files ignored due to path filters (1)
  • package-lock.json is excluded by !**/package-lock.json
📒 Files selected for processing (1)
  • src/apps/pulse/hooks/useIntentSdk.ts (3 hunks)
🧰 Additional context used
🧠 Learnings (3)
📚 Learning: 2025-11-04T14:34:00.373Z
Learnt from: RanaBug
Repo: pillarwallet/x PR: 445
File: src/containers/Authorized.tsx:63-77
Timestamp: 2025-11-04T14:34:00.373Z
Learning: In src/containers/Authorized.tsx, the tempKit useEffect intentionally excludes chainId from its dependency array because the kit is used by useWalletModeVerification to check wallet mode across all supported chains, regardless of the currently selected chainId. The chainId parameter is only used for initial kit configuration and does not affect the multi-chain verification results.

Applied to files:

  • src/apps/pulse/hooks/useIntentSdk.ts
📚 Learning: 2025-08-20T09:14:16.888Z
Learnt from: RanaBug
Repo: pillarwallet/x PR: 374
File: src/apps/pillarx-app/index.tsx:12-12
Timestamp: 2025-08-20T09:14:16.888Z
Learning: In this codebase, Transaction Kit providers are set up at the container level (src/containers/Authorized.tsx), not at individual app component levels. App components like src/apps/pillarx-app/index.tsx are children that consume the context through the provider tree.

Applied to files:

  • src/apps/pulse/hooks/useIntentSdk.ts
📚 Learning: 2025-08-12T07:42:24.656Z
Learnt from: IAmKio
Repo: pillarwallet/x PR: 351
File: src/apps/pulse/utils/intent.ts:44-53
Timestamp: 2025-08-12T07:42:24.656Z
Learning: In the Pulse app's intent utilities (src/apps/pulse/utils/intent.ts), the team has chosen to use floating-point arithmetic for token amount calculations despite potential precision issues, accepting JavaScript's decimal place limitations as a valid trade-off for their use case.

Applied to files:

  • src/apps/pulse/hooks/useIntentSdk.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: unit-tests
  • GitHub Check: lint
  • GitHub Check: build
🔇 Additional comments (1)
src/apps/pulse/hooks/useIntentSdk.ts (1)

119-119: Use a proper type adapter or narrow the type safely instead of as any.

The type cast on line 119 is part of a systematic pattern in this file (lines 46, 82, 119) and appears elsewhere in the codebase (e.g., the-exchange/index.tsx line 73). The as any cast indicates a type mismatch between Transaction Kit's wallet client and IntentSdk's expected viem-based wallet client type.

Verification shows:

  • IntentSdk (v1.0.0-alpha.10) depends on viem@2.21.53
  • walletClient comes from kit.getEtherspotProvider().getWalletClient() (Transaction Kit)
  • Multiple uses of as any for this same cast suggest a known incompatibility

Rather than relying on as any across multiple call sites, consider:

  1. Creating a type adapter or wrapper function to safely bridge Transaction Kit's wallet client to IntentSdk's expectations
  2. Verifying the actual runtime compatibility and updating IntentSdk type definitions if needed
  3. If using an alpha version of IntentSdk, checking if newer versions have improved type definitions

Comment on lines +12 to +21
// const { ready, authenticated, user } = usePrivy();
// const { wallets } = useWallets();
// const { isConnected: isWagmiConnected } = useAccount();
// const { connectors } = useConnect();

const privyWalletAddress = user?.wallet?.address;
// const privyWalletAddress = user?.wallet?.address;

const walletProvider = wallets.find(
(wallet) => wallet.address === privyWalletAddress
);
// const walletProvider = wallets.find(
// (wallet) => wallet.address === privyWalletAddress
// );
Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion | 🟠 Major

Remove commented-out code.

Lines 12-21 contain commented imports and logic from the previous Privy-based implementation. Once the Transaction Kit migration is confirmed working, this dead code should be removed to improve maintainability.

Apply this diff to remove the commented code:

  const { walletAddress: accountAddress, kit } = useTransactionKit();
-  // const { ready, authenticated, user } = usePrivy();
-  // const { wallets } = useWallets();
-  // const { isConnected: isWagmiConnected } = useAccount();
-  // const { connectors } = useConnect();
-
-  // const privyWalletAddress = user?.wallet?.address;
-
-  // const walletProvider = wallets.find(
-  //   (wallet) => wallet.address === privyWalletAddress
-  // );
+
   const [intentSdk, setIntentSdk] = useState<IntentSdk | null>(null);
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
// const { ready, authenticated, user } = usePrivy();
// const { wallets } = useWallets();
// const { isConnected: isWagmiConnected } = useAccount();
// const { connectors } = useConnect();
const privyWalletAddress = user?.wallet?.address;
// const privyWalletAddress = user?.wallet?.address;
const walletProvider = wallets.find(
(wallet) => wallet.address === privyWalletAddress
);
// const walletProvider = wallets.find(
// (wallet) => wallet.address === privyWalletAddress
// );
const { walletAddress: accountAddress, kit } = useTransactionKit();
const [intentSdk, setIntentSdk] = useState<IntentSdk | null>(null);
🤖 Prompt for AI Agents
In src/apps/pulse/hooks/useIntentSdk.ts around lines 12 to 21, remove the
leftover commented-out Privy/Wallet related imports and logic (the commented
const lines and wallets/find block) to eliminate dead code; delete those
commented lines and ensure surrounding code formatting remains correct and
imports are updated if any unused imports remain.

Comment on lines +38 to +89
// if (ready && authenticated && walletProvider) {
// console.log('Initializing Intent SDK via Privy wallet');
// const provider = await walletProvider.getEthereumProvider();
// const walletClient = createWalletClient({
// account: walletProvider.address as Hex,
// transport: custom(provider),
// });
// /* eslint-disable @typescript-eslint/no-explicit-any */
// const sdk = new IntentSdk(walletClient as any, options);
// console.log('Initialized Intent SDK via Privy wallet');
// setIntentSdk(sdk);
// setError(null);
// return;
// }

// // 2: Check if connected via WalletConnect (only if no Privy wallet)
// const hasWallets = walletProvider !== undefined;
// if (isWagmiConnected && !hasWallets) {
// console.log('Initializing Intent SDK via WalletConnect');
// const walletConnectConnector = connectors.find(
// ({ id }) => id === 'walletConnect'
// );

// if (walletConnectConnector) {
// const wcProvider: any = await walletConnectConnector.getProvider();

// // Only proceed if the provider is actually connected
// if (
// wcProvider &&
// wcProvider.connected &&
// wcProvider.accounts &&
// wcProvider.accounts.length > 0
// ) {
// // Get the connected account
// const accounts = await wcProvider.request({
// method: 'eth_accounts',
// });
// const wcAccount = accounts[0];

// if (wcAccount) {
// const walletClient = createWalletClient({
// account: wcAccount as Hex,
// transport: custom(wcProvider),
// });
// const sdk = new IntentSdk(walletClient as any, options);
// setIntentSdk(sdk);
// console.log('Initialized Intent SDK via WalletConnect');
// setError(null);
// }
// }
// }
// }
Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion | 🟠 Major

Remove 52 lines of commented-out initialization logic.

Lines 38-89 contain the entire Privy and WalletConnect initialization flow that has been replaced by Transaction Kit. This commented code should be removed once the new implementation is verified in production.

Apply this diff to remove the commented initialization logic:

       try {
         console.log('Attempting to initialize Intent SDK');
-        // 1: Check if connected via Privy wallet
-        // if (ready && authenticated && walletProvider) {
-        //   console.log('Initializing Intent SDK via Privy wallet');
-        //   const provider = await walletProvider.getEthereumProvider();
-        //   const walletClient = createWalletClient({
-        //     account: walletProvider.address as Hex,
-        //     transport: custom(provider),
-        //   });
-        //   /* eslint-disable @typescript-eslint/no-explicit-any */
-        //   const sdk = new IntentSdk(walletClient as any, options);
-        //   console.log('Initialized Intent SDK via Privy wallet');
-        //   setIntentSdk(sdk);
-        //   setError(null);
-        //   return;
-        // }
-
-        // // 2: Check if connected via WalletConnect (only if no Privy wallet)
-        // const hasWallets = walletProvider !== undefined;
-        // if (isWagmiConnected && !hasWallets) {
-        //   console.log('Initializing Intent SDK via WalletConnect');
-        //   const walletConnectConnector = connectors.find(
-        //     ({ id }) => id === 'walletConnect'
-        //   );
-
-        //   if (walletConnectConnector) {
-        //     const wcProvider: any = await walletConnectConnector.getProvider();
-
-        //     // Only proceed if the provider is actually connected
-        //     if (
-        //       wcProvider &&
-        //       wcProvider.connected &&
-        //       wcProvider.accounts &&
-        //       wcProvider.accounts.length > 0
-        //     ) {
-        //       // Get the connected account
-        //       const accounts = await wcProvider.request({
-        //         method: 'eth_accounts',
-        //       });
-        //       const wcAccount = accounts[0];
-
-        //       if (wcAccount) {
-        //         const walletClient = createWalletClient({
-        //           account: wcAccount as Hex,
-        //           transport: custom(wcProvider),
-        //         });
-        //         const sdk = new IntentSdk(walletClient as any, options);
-        //         setIntentSdk(sdk);
-        //         console.log('Initialized Intent SDK via WalletConnect');
-        //         setError(null);
-        //       }
-        //     }
-        //   }
-        // }
-
-        // 3: Check if Transaction Kit is available
+
         if (!kit) {
🤖 Prompt for AI Agents
In src/apps/pulse/hooks/useIntentSdk.ts around lines 38 to 89, remove the entire
52-line block of commented-out Privy and WalletConnect initialization (the
commented code from the previous Intent SDK flow). Delete those commented lines,
run the linter/formatter, and remove any now-unused imports or variables
introduced solely for that removed code; then run tests or a quick local
verification to ensure no references remain.

Comment on lines +136 to +140
// ready,
// authenticated,
// walletProvider,
// isWagmiConnected,
// connectors,
Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion | 🟠 Major

Remove commented-out dependency array entries.

Lines 136-140 contain commented dependency entries from the previous implementation. Clean up the dependency array to only include active dependencies.

Apply this diff:

-  }, [
-    accountAddress,
-    kit,
-    // ready,
-    // authenticated,
-    // walletProvider,
-    // isWagmiConnected,
-    // connectors,
-  ]);
+  }, [accountAddress, kit]);

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents
In src/apps/pulse/hooks/useIntentSdk.ts around lines 136 to 140, the dependency
array contains leftover commented-out entries (ready, authenticated,
walletProvider, isWagmiConnected, connectors); remove these commented lines so
the dependency array only contains active dependencies and nothing commented,
keeping formatting consistent and ensuring no trailing commas or extraneous
whitespace remain.

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.

2 participants