<h3>Greptile Summary</h3>

[markusknudtsen-droid]

Greptile Summary

Replaced batched transaction fetching (getParsedTransactions) with sequential individual requests (getParsedTransaction) to prevent RPC rate limiting (429 errors).

Key changes:

• Removed MAX_TRANSACTION_BATCH_SIZE constant (was 10)
• • • Added TRANSACTION_FETCH_DELAY_MS constant (100s delay between requests)
• Implemented sequential fetching with delays instead of batching
• Added per-transaction error handling with try-catch and warning logs
• Individual transaction failures no longer block fetching remaining transactions

Trade-offs:

• Slower overall fetch time (~2.5s for 25 transactions vs ~175s with batching)
• Better resilience to rate limits and individual transaction errors
• Improved error visibility with per-transaction warnings

Confidence Score: 3/5

• This PR is safe to merge but introduces performance trade-offs that should be monitored
• The change successfully addresses rate limiting issues with a straightforward solution, and includes better error handling. However, it introduces significant performance degradation (10x+ slower) which could impact user experience. The approach is a workaround rather than a proper solution - the PR author notes making calls from the backend would be better. The implementation is correct and won't cause functional issues, but the performance impact and lack of backend implementation lower confidence.
• No files require special attention - the single changed file has clear logic and proper error handling

Important Files Changed

Filename	Overview

• | app/providers/accountsGhnug6zaKY1LR4rEHrpvyzbyZ7NqrYawK1JqqYWnLEEy/history.tsx | Replaced batch transaction fetching with sequential individual requests to avoid rate limiting, added error handling per transaction, introduced 100ms delay between requests | #860

_{Last reviewed commit: 4c391bf}

Originally posted by @greptile-apps[bot] in #854 (comment)

[Sushil-19]

Instead of fully sequential fetching with artificial delay, we could introduce limited concurrency (e.g. 5 parallel requests) with retry-on-429 backoff. That would preserve resilience while improving performance significantly.

[rogaldh]

The latest implementation already uses concurrency with a backoff upon errors.