new pool notif handler

[rouzwelt]

Motivation

Solution

Checks

By submitting this for review, I'm confirming I've done the following:

• made this PR as small as possible
• unit-tested any new functionality
• linked any relevant issues or PRs
• included screenshots (if this involves a front-end change)

Summary by CodeRabbit

• Refactor
  • Enhanced pool initialization state tracking and refined router processing logic for improved operational reliability.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Changes propagate pool creation state information from SushiRouter.update() through initializeRound and into prepareRouter, enabling conditional skip logic based on whether a new pool was created at the start of a batch.

Changes

Cohort / File(s)	Summary
Pool creation state propagation src/core/process/round.ts	Introduces newPoolCreated flag captured from sushi.update(blockNumber) result; passes flag to prepareRouter signature; adjusts guard condition to conditionally skip processing when new pool was not created and cached value exceeds threshold
SushiRouter update method src/router/sushi/index.ts	Changes SushiRouter.update() to return Promise<boolean> indicating pool update success instead of returning void

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Guard logic change in prepareRouter: Verify the conditional skip behavior correctly distinguishes between new pool creation and cached threshold scenarios
• Return type propagation: Confirm the boolean return value from dataFetcher.updatePools() accurately reflects update success and is properly handled at the call site in initializeRound

Pre-merge checks and finishing touches

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title 'new pool notif handler' is vague and does not clearly describe the actual changes in the pull request, which involve tracking pool creation state and conditional logic in the router.	Consider using a more descriptive title such as 'Track pool creation state in router initialization' or 'Add pool creation flag to prepareRouter logic' to better reflect the actual changes.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ 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 2025-12-06-new-pool-wtacher

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 39c5846 and 8ee445c.

📒 Files selected for processing (2)

• src/core/process/round.ts (2 hunks)
• src/router/sushi/index.ts (1 hunks)

🧰 Additional context used

🧠 Learnings (1)

📚 Learning: 2025-10-15T16:54:59.124Z

Learnt from: rouzwelt
Repo: rainlanguage/rain.solver PR: 409
File: src/router/types.ts:47-47
Timestamp: 2025-10-15T16:54:59.124Z
Learning: In the rain.solver codebase, it is acceptable to include `sushiRouter?: SushiRouter` in `RainSolverRouterQuoteParams` type. SushiRouter is the main router with the most liquidity and token support, and it may be used elsewhere in the codebase to get token prices, so passing it in quote params is justified despite introducing coupling.

Applied to files:

• src/router/sushi/index.ts
• src/core/process/round.ts

🧬 Code graph analysis (1)

src/core/process/round.ts (3)

src/index.ts (1)

• RainSolver (4-4)

src/core/index.ts (1)

• RainSolver (27-94)

src/order/types/index.ts (1)

• Pair (132-132)

🔇 Additional comments (3)

src/core/process/round.ts (2)

56-60: LGTM! Well-handled optional router and error cases.

The initialization and error handling for newPoolCreated is sound:

• Defaults to false when router is undefined or update fails
• Optional chaining (?.) safely handles missing sushi router
• .catch(() => false) provides sensible fallback for update errors
• ?? false covers the undefined case from optional chaining

This ensures the flag always has a valid boolean value for downstream logic.

---

103-111: LGTM! Cache bypass logic correctly tied to pool updates.

The updated guard condition properly implements the intended behavior:

• Skip preparation only when !newPoolCreated && value > 3
• Always prepare when newPoolCreated === true, bypassing cache

This ensures that when fresh pool data is available (new pool created/updated), market prices are refetched even if they were recently cached. The optional parameter maintains backward compatibility while the !newPoolCreated check correctly handles both false and undefined as "no new pool."

src/router/sushi/index.ts (1)

255-256: Fix type mismatch: update() return type declaration doesn't match actual behavior.

The method declares Promise<boolean> as its return type, but tests mock dataFetcher.updatePools() to return undefined (lines 449, 458 in the test file). Since update() directly returns the result from dataFetcher.updatePools() without transformation, the actual return type is Promise<boolean | undefined> or Promise<void>, not Promise<boolean>. Update the type signature to match the actual return type from the underlying updatePools() method in the sushi package, or ensure the return value is properly transformed to a boolean.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

@coderabbitai assess this PR size classification for the totality of the PR with the following criterias and report it in your comment:

S/M/L PR Classification Guidelines:

This guide helps classify merged pull requests by effort and complexity rather than just line count. The goal is to assess the difficulty and scope of changes after they have been completed.

Small (S)

Characteristics:

• Simple bug fixes, typos, or minor refactoring
• Single-purpose changes affecting 1-2 files
• Documentation updates
• Configuration tweaks
• Changes that require minimal context to review

Review Effort: Would have taken 5-10 minutes

Examples:

• Fix typo in variable name
• Update README with new instructions
• Adjust configuration values
• Simple one-line bug fixes
• Import statement cleanup

Medium (M)

Characteristics:

• Feature additions or enhancements
• Refactoring that touches multiple files but maintains existing behavior
• Breaking changes with backward compatibility
• Changes requiring some domain knowledge to review

Review Effort: Would have taken 15-30 minutes

Examples:

• Add new feature or component
• Refactor common utility functions
• Update dependencies with minor breaking changes
• Add new component with tests
• Performance optimizations
• More complex bug fixes

Large (L)

Characteristics:

• Major feature implementations
• Breaking changes or API redesigns
• Complex refactoring across multiple modules
• New architectural patterns or significant design changes
• Changes requiring deep context and multiple review rounds

Review Effort: Would have taken 45+ minutes

Examples:

• Complete new feature with frontend/backend changes
• Protocol upgrades or breaking changes
• Major architectural refactoring
• Framework or technology upgrades

Additional Factors to Consider

When deciding between sizes, also consider:

• Test coverage impact: More comprehensive test changes lean toward larger classification
• Risk level: Changes to critical systems bump up a size category
• Team familiarity: Novel patterns or technologies increase complexity

Notes:

• the assessment must be for the totality of the PR, that means comparing the base branch to the last commit of the PR
• the assessment output must be exactly one of: S, M or L (single-line comment) in format of: SIZE={S/M/L}
• do not include any additional text, only the size classification
• your assessment comment must not include tips or additional sections
• do NOT tag me or anyone else on your comment

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Get the PR diff to verify the totality of changes
gh pr diff 422 --repo rainlanguage/rain.solver

Length of output: 2412

---

SIZE=M