[BUG]: The Rebalance Pool should not be restricted to only auction owner and investigate and fix the console warnings related to fetchLastRebalanceEvent

[VishwajeetTulse]

Bug Description

The "Rebalance Pool" section in the pool interaction page (/[pool]) has three distinct issues:

1. Incorrect Access Control (Public Function Restricted)
The rebalance() smart contract function is public, but the frontend blocks non-creators from using it.

• Access Issue: The button is disabled for all wallets except the pool creator showing a "creator only" tooltip.
• Logic Bug: Due to an operator precedence error (&& before ||), the disabled check fails for disconnected wallets, making the button incorrectly clickable when no wallet is connected.
• Location: src/app/[pool]/InteractionClient.tsx ~line 1363

2. Stale Data After Rebalance
The pool data (reserves, prices, percentages) does not automatically update after a successful rebalance transaction. The page requires a manual reload to reflect the new state because refetchPool isn't triggered correctly on confirmation.

• Location: src/app/[pool]/InteractionClient.tsx ~line 1065

3. False Console Warning
A warning (WARN: All approaches failed – No rebalance events found) appears in the console even after a successful rebalance. The event fetching logic fails to find the new event immediately, triggering a misleading warning despite the operation succeeding.

• Location: src/app/[pool]/InteractionClient.tsx ~line 773

Proposed Fixes

Bug 1 — Remove incorrect creator-only restriction

Changes needed in src/app/[pool]/InteractionClient.tsx ~line 1363:

1. Fix the disabled logic to allow any connected wallet to call rebalance:

// Current (buggy)
disabled={
  address !== pool?.vault_creator && address !== undefined ||
  isDistributeLoading
}

// Fixed
disabled={
  !isConnected || 
  !address || 
  isDistributeLoading ||
  isTransactionPending
}

2. Remove the creator-only tooltip (~line 1374-1380):
   • Remove the entire conditional tooltip that says "This action can only be performed by the pool creator"
   • Or replace it with a generic tooltip explaining what rebalance does

Impact: Any connected wallet will be able to trigger rebalance, matching the smart contract's public external nonReentrant function signature.

---

Bug 2 — Ensure post-rebalance data refresh

Changes needed in src/app/[pool]/InteractionClient.tsx ~line 1065:

1. Replace handlePoll with direct refetchPool call in the confirmation useEffect:

// Current
handlePoll();

// Fixed
await refetchPool?.();

2. Optionally add a slight delay to ensure blockchain state propagates:

setTimeout(async () => {
  await refetchPool?.();
  logger.debug('Pool data refreshed after rebalance confirmation');
}, 1000);

3. Alternative approach: Invalidate and refetch ALL contract reads related to the pool (reserves, prices, balances) to ensure complete UI update.

Impact: Pool data (reserves, percentages, token prices) will automatically update after a successful rebalance without requiring a manual page reload.

---

Bug 3 — Downgrade false warning to debug level

Changes needed in src/app/[pool]/InteractionClient.tsx ~line 773:

Replace:

logger.warn('All approaches failed - No rebalance events found for pool:', { poolId });

With:

logger.debug('No rebalance events found in blockchain history - this is expected for new pools or if RPC indexing is delayed. Using localStorage fallback.', { poolId });

Rationale:

• lastRebalanceTime is persisted in localStorage immediately when rebalance is called, making it the source of truth
• Event fetching is supplementary verification, not critical functionality
• For newly created pools that have never been rebalanced, zero events is expected behavior
• RPC nodes may have indexing delays after a fresh rebalance
• The warn level incorrectly suggests a problem when the system is working as designed

Impact: Removes misleading console warnings that appear even when the rebalance feature is functioning correctly.

---

Logs and Screenshots

Bug 1 (Creator-only restriction):

---

Environment Details

• Files affected:
  • src/app/[pool]/InteractionClient.tsx (lines ~773, ~1065, ~1363)
• Framework: Next.js (React)
• Smart Contract: PredictionPool ABI (rebalance() is external nonReentrant)
• Blockchain interaction: wagmi hooks (useWriteContract, useWaitForTransactionReceipt, useReadContracts)
• Browser: Chrome 120+ / Firefox / Safari (any modern browser)
• OS: Windows 11 / macOS / Linux
• Node.js: v18+ (as per project requirements)

---

Impact

Medium - Feature works but has issues

Code of Conduct

• I have joined the Discord server and will post updates there
• I have searched existing issues to avoid duplicates

[VishwajeetTulse]

Hey @blizet I've been doing a deeper investigation into Bug 3 (the false console warning) and found it's more significant than I initially anticipated. Here's what I found:

The warning fires because fetchLastRebalanceEvent fails to find any Rebalanced events on-chain. I initially thought this was a false alarm, but it seems to be a real failure. Here's the breakdown:

1. All three approaches use fromBlock: 'earliest' which exceeds the block range limit of most public RPC providers (typically 2,000–10,000 blocks). This means the query silently fails for both Sepolia and Ethereum Classic, and ETC is worse since it has been producing blocks since 2016. As I confirmed from browser console that the Thirdweb Sepolia RPC returns RpcRequestError: eth_getLogs is limited to a 10,000 range (code -32614) for all three approaches. Approach 3 also fails despite being designed as "last 10,000 blocks", because fromBlock: 0x9df8f9 to toBlock: 'latest' resolves server-side to a range slightly over 10,000.

2. The publicClient is created using http() with no RPC URL, which falls back to the chain's default public endpoint (etc.rivet.link for ETC). This is a rate-limited, unauthenticated endpoint making reliable log queries near-impossible.

3. Both the inline event ABI redeclaration and the topic-count heuristic in the fallback approaches are unreliable. All three approaches throw the same RpcRequestError with "details": "eth_getLogs is limited to a 10,000 range". The errors were being swallowed by the individual catch blocks and only surfaced after adding diagnostic logging.

4. Non-connected users are completely blocked from seeing rebalance history because the function returns early if walletClient is missing, meaning the "Last rebalanced: Never" displayed is wrong for all non-connected visitors regardless of pool history.

5. There's also no concurrency protection, rapid refreshes can trigger multiple simultaneous calls.

We need to use the transaction receipt directly (already available via rebalanceHash) to get the timestamp for the current session, and use a reverse paginated scan in small chunks for other users, stopping immediately on the first hit. A reverse-paginated scan using 9,000-block chunks (safely under the 10,000-block cap) can implemented and applied. The WARN: All approaches failed message should no longer appear for pools rebalanced within the scan window (~25 days on Sepolia). The walletClient gate issue (point 4) is a separate follow-up.

Let me know if you'd like me to go ahead.

[VishwajeetTulse]

@blizet what should I do next?

[blizet]

@VishwajeetTulse Nice work! The paginated scan works for now, go ahead with it. Ideally we'd store lastRebalancedAt on the contract and read it as a free eth_call which would solve this cleanly, but that needs a redeployment so your approach makes sense for now.