-
Notifications
You must be signed in to change notification settings - Fork 0
return pool creation result for process log #41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
WalkthroughMultiple router providers and the base liquidity provider were changed to return booleans from their event-processing methods; RainDataFetcher.updatePools now returns Promise and aggregates provider boolean results to indicate whether any new pools were created. NileV2Provider was removed from the providers list and a CI workflow was added. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Suggested labels
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: ASSERTIVE Plan: Pro 📒 Files selected for processing (1)
🧰 Additional context used🧠 Learnings (7)📓 Common learnings📚 Learning: 2025-04-09T16:38:40.404ZApplied to files:
📚 Learning: 2025-04-08T19:08:36.306ZApplied to files:
📚 Learning: 2025-04-08T21:48:34.425ZApplied to files:
📚 Learning: 2025-11-27T23:22:08.828ZApplied to files:
📚 Learning: 2025-04-09T16:44:17.669ZApplied to files:
📚 Learning: 2025-04-09T15:38:12.307ZApplied to files:
⏰ 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). (20)
🔇 Additional comments (4)
Comment |
There was a problem hiding this 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
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/sushi/src/router/data-fetcher.ts (1)
185-285: NileV2Provider is silently disabled here; consider explicit deprecation or cleanup.Commenting out
NileV2Providerin_setProviders(and dropping its import) means routes will no longer include Nile V2 pools, but any config or code that still references aLiquidityProviders.NileV2enum value will now be effectively ignored with no obvious signal.If Nile V2 is permanently deprecated, it would be cleaner to:
- Remove
NileV2Providerfrom the provider list entirely (rather than leaving it commented), and- Remove or clearly deprecate any corresponding enum entries / wiring (if they still exist), or
- Add a short comment explaining why it’s disabled (e.g., “temporarily disabled due to broken subgraph / contracts”).
This makes the behavior change explicit and reduces confusion for future maintainers.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
.github/workflows/git-clean.yml(1 hunks)packages/sushi/src/router/data-fetcher.ts(1 hunks)packages/sushi/src/router/rain/RainDataFetcher.ts(5 hunks)
🧰 Additional context used
🧠 Learnings (6)
📚 Learning: 2025-04-09T16:38:40.404Z
Learnt from: rouzwelt
Repo: rainlanguage/sushiswap PR: 32
File: packages/sushi/src/router/rain/UniswapV3Base.ts:71-92
Timestamp: 2025-04-09T16:38:40.404Z
Learning: In packages/sushi/src/router/rain/UniswapV3Base.ts, the fetchPoolData method uses multicall where each pool returns its own response independently, and failures are handled at the individual pool level rather than affecting all pools at once.
Applied to files:
packages/sushi/src/router/rain/RainDataFetcher.ts
📚 Learning: 2025-04-08T19:08:36.306Z
Learnt from: rouzwelt
Repo: rainlanguage/sushiswap PR: 32
File: packages/sushi/src/router/rain/UniswapV3Base.ts:169-210
Timestamp: 2025-04-08T19:08:36.306Z
Learning: In packages/sushi/src/router/rain/UniswapV3Base.ts, the methods getIndexes and fetchPoolsForToken are separate methods with distinct responsibilities and not closely interlinked as might be assumed.
Applied to files:
packages/sushi/src/router/rain/RainDataFetcher.ts
📚 Learning: 2025-04-08T21:48:34.425Z
Learnt from: rouzwelt
Repo: rainlanguage/sushiswap PR: 32
File: packages/sushi/src/router/rain/UniswapV3Base.ts:93-117
Timestamp: 2025-04-08T21:48:34.425Z
Learning: In the SushiSwap router implementation, error handling for multicall failures in methods like `fetchPoolData` is simplified (logging and returning undefined) because it's handled downstream in the calling code.
Applied to files:
packages/sushi/src/router/rain/RainDataFetcher.ts
📚 Learning: 2025-11-27T23:22:08.828Z
Learnt from: rouzwelt
Repo: rainlanguage/sushiswap PR: 40
File: protocols/route-processor/test/DataFetcher.test.ts:242-271
Timestamp: 2025-11-27T23:22:08.828Z
Learning: In protocols/route-processor/test/DataFetcher.test.ts, the 60-second sleep delays between test branches are intentional and necessary due to rate limiting constraints on public RPCs. These sleeps should not be reduced or conditionally gated.
Applied to files:
packages/sushi/src/router/rain/RainDataFetcher.ts
📚 Learning: 2025-04-09T15:38:12.307Z
Learnt from: rouzwelt
Repo: rainlanguage/sushiswap PR: 32
File: packages/sushi/src/router/rain/UniswapV2Base.ts:127-144
Timestamp: 2025-04-09T15:38:12.307Z
Learning: In blockchain event processing systems, logs arrive in order, which explains the design choice to check log.blockNumber against pool.blockNumber and only process newer logs.
Applied to files:
packages/sushi/src/router/rain/RainDataFetcher.ts
📚 Learning: 2025-04-09T16:44:17.669Z
Learnt from: rouzwelt
Repo: rainlanguage/sushiswap PR: 32
File: packages/sushi/src/router/rain/RainDataFetcher.ts:317-339
Timestamp: 2025-04-09T16:44:17.669Z
Learning: The `processLog` method in router providers is synchronous and must process blockchain logs sequentially to maintain consistent state between events.
Applied to files:
packages/sushi/src/router/rain/RainDataFetcher.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). (20)
- GitHub Check: git-clean
- GitHub Check: datafetcher-test (FLARE)
- GitHub Check: datafetcher-test (BASE)
- GitHub Check: datafetcher-test (FILECOIN)
- GitHub Check: datafetcher-test (FUSE)
- GitHub Check: datafetcher-test (OPTIMISM)
- GitHub Check: datafetcher-test (BOBA_BNB)
- GitHub Check: datafetcher-test (POLYGON_ZKEVM)
- GitHub Check: datafetcher-test (METIS)
- GitHub Check: datafetcher-test (KAVA)
- GitHub Check: datafetcher-test (TELOS)
- GitHub Check: datafetcher-test (CELO)
- GitHub Check: datafetcher-test (ARBITRUM_NOVA)
- GitHub Check: datafetcher-test (OKEX)
- GitHub Check: datafetcher-test (ARBITRUM)
- GitHub Check: datafetcher-test (AVALANCHE)
- GitHub Check: datafetcher-test (HARMONY)
- GitHub Check: datafetcher-test (BSC)
- GitHub Check: datafetcher-test (FANTOM)
- GitHub Check: router-test
🔇 Additional comments (3)
.github/workflows/git-clean.yml (1)
1-38: Clarify the workflow's purpose and verify build scope aligns with PR changes.The workflow appears to run post-push and checks for uncommitted changes—a check that typically prevents code from being committed in the first place. This suggests the workflow may be misconfigured or its purpose is unclear.
Additionally, the build step (line 31) scopes to
./packages/sushionly, but the PR's summary indicates changes across multiple liquidity provider classes and data fetchers. Verify that this build scope is sufficient to exercise all the boolean return-type changes described in the PR.Please clarify:
- Is this workflow intended as post-commit validation (in which case the
git diff --exit-codecheck is redundant), or as a pre-commit guard (which would be better suited for a pre-commit hook or pull-request workflow)?- Does the
./packages/sushibuild scope fully cover the changes described in the PR (liquidity provider classes and RainDataFetcher updates)?- Is the scoped build intentional, or should it build the entire workspace?
packages/sushi/src/router/rain/RainDataFetcher.ts (2)
321-333: LGTM!The early return paths correctly return
falsefor cases where no pool updates occur: uninitialized state, already synced, or empty pool list. These semantically represent "no new pool was created."
282-286: Based on my comprehensive verification, I can now provide the rewritten review comment:
Public API change:
updatePoolsnow returnsPromise<boolean>indicating new pool creation.The signature change and documentation update are correct. The method properly returns
falsein early exit cases and accumulates a flag tracking whether any logs indicated new pool creation. The sole internal caller at line 478 safely ignores the return value, maintaining backward compatibility—returning a value from a previously void-returning function does not break existing code that ignores it. Tests in RainDataFetcher.test.ts work without modification.
Motivation
Solution
Checks
By submitting this for review, I'm confirming I've done the following:
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.