fix(minibf): Fetch pool metadata in parallel

[gonzalezzfelipe]

Summary by CodeRabbit

• New Features

  • Implemented parallel fetching of pool metadata for faster data retrieval

• Refactor

  • Optimized metadata request performance with adjusted timeout
  • Improved robustness when off-chain metadata is unavailable

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

[coderabbitai]

Walkthrough

Added futures dependency to enable parallel fetching of pool off-chain metadata. Refactored all_extended function to fetch metadata concurrently using join_all instead of synchronously per-pool, and reduced metadata request timeout from 10 seconds to 5 seconds.

Changes

Cohort / File(s)	Summary
Dependency Addition crates/minibf/Cargo.toml	Added futures = "0.3.31" dependency to support concurrent operations.
Metadata Fetching Refactor crates/minibf/src/routes/pools.rs	Introduced parallel fetching of pool off-chain metadata using join_all; reduced request timeout from 10s to 5s; reworked metadata integration to use concurrent fetch results, with graceful handling of absent off-chain data by setting fields to None.

Sequence Diagram

sequenceDiagram
    participant old as Old Flow
    participant new as New Flow
    participant svc as Service/API
    
    rect rgb(200, 220, 255)
        Note over old: Synchronous (Sequential)
        old->>svc: fetch metadata pool 1
        activate svc
        svc-->>old: response
        deactivate svc
        old->>svc: fetch metadata pool 2
        activate svc
        svc-->>old: response
        deactivate svc
        old->>svc: fetch metadata pool 3
        activate svc
        svc-->>old: response
        deactivate svc
    end
    
    rect rgb(220, 255, 220)
        Note over new: Concurrent (Parallel with join_all)
        par
            new->>svc: fetch metadata pool 1
            new->>svc: fetch metadata pool 2
            new->>svc: fetch metadata pool 3
        and
            activate svc
            svc-->>new: response 1
            svc-->>new: response 2
            svc-->>new: response 3
            deactivate svc
        end
    end
    
    Note over new: Build PoolListExtendedInner<br/>with concurrent results

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Specific areas requiring attention:
  • Async/concurrent logic implementation with join_all in all_extended function to verify correctness of parallel execution and error handling
  • Timeout reduction from 10s to 5s and its implications on reliability and performance under various network conditions
  • Metadata integration logic handling of both present and absent off-chain data to ensure graceful fallbacks

Possibly related PRs

• fix: Improve pools and rewards endpoints #784: Both PRs modify pool metadata fetching in all_extended by introducing concurrent/async metadata fetching and updating metadata-driven logic.

Suggested reviewers

• scarmuega

Poem

🐰 A rabbit hopped through concurrent streams,
Fetching metadata in parallel dreams,
From five to five, the timeout shrinks,
Join all the pools before you blink! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

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.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The PR title 'fix(minibf): Fetch pool metadata in parallel' accurately describes the main change: introducing parallel fetching of pool off-chain metadata using join_all, which is the primary technical improvement in the changeset.

✨ 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/pools-extended-timeout

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

crates/minibf/src/routes/pools.rs (2)

44-58: Timeout reduced to 5s; consider configurability and client reuse

Dropping the HTTP timeout to 5 seconds will help cap tail latency but may cause more metadata misses for slower endpoints. Since this value is now performance‑critical (and duplicated across many parallel calls), consider making it a named constant or configuration option, and reusing a shared HTTP client instead of building a new one per call to reduce connection‑pool overhead.

---

17-17: Parallel metadata fetch is unbounded; consider limiting concurrency and reusing the client

join_all over metadata_futures will issue one HTTP request per pool concurrently, and each future currently builds its own client via pool_offchain_metadata. With many pools this can mean a large, spiky number of outbound connections and client instances.

It would be safer to:

• Reuse a single HTTP client for all metadata lookups, and
• Bound concurrency (e.g., with futures::stream::iter(...).map(...).buffer_unordered(N) or a semaphore) so you still get parallelism without potentially overwhelming the host or your process.

This keeps the new behavior (faster aggregate latency) while avoiding resource‑exhaustion risks.

Also applies to: 122-138, 141-141

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 98a7be5 and 4c0b875.

⛔ Files ignored due to path filters (1)

• Cargo.lock is excluded by !**/*.lock

📒 Files selected for processing (2)

• crates/minibf/Cargo.toml (1 hunks)
• crates/minibf/src/routes/pools.rs (3 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

crates/minibf/src/routes/pools.rs (1)

crates/minibf/src/mapping.rs (1)

• bech32_pool (104-106)

⏰ 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). (1)

• GitHub Check: Check Build

🔇 Additional comments (2)

crates/minibf/Cargo.toml (1)

27-30: futures dependency addition looks appropriate

Adding futures = "0.3.31" here matches how other direct dependencies are pinned and aligns with the new join_all usage in pools.rs. No manifest issues from this change; just ensure you’re not accidentally pulling in multiple futures major versions elsewhere in the workspace.

crates/minibf/src/routes/pools.rs (1)

145-172: Behavior change claim is unsupported by the code changes

The review comment attributes a metadata null-handling behavior to this PR, but verification shows this behavior pre-existed before commit 4c0b875. The git diff reveals the commit only refactors metadata fetching from sequential to parallel execution using join_all(). The identical null-handling logic (returning None::<String> for ticker/name/description/homepage when off-chain metadata is unavailable) was already present in the parent commit. No actual API behavior change regarding metadata nulls was introduced by this PR—the refactoring is strictly mechanical.

Likely an incorrect or invalid review comment.