chore: Update u5c

[gonzalezzfelipe]

Summary by CodeRabbit

Release Notes

• Bug Fixes

  • Improved event handling robustness with explicit management of edge cases
  • Enhanced error propagation and handling in ledger operations

• Chores

  • Updated utxorpc dependency to version 0.12.0

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

[coderabbitai]

Walkthrough

Dependency bump for utxorpc (0.10.0 → 0.12.0), restructured event handling in chainsync driver with explicit None branches, refactored read_params error handling, and updated ChainPoint/BlockRef construction to use slot field instead of index with added height field.

Changes

Cohort / File(s)	Summary
Dependency Update balius-runtime/Cargo.toml	utxorpc version bumped from 0.10.0 to 0.12.0
Event Handling Restructuring balius-runtime/src/drivers/chainsync.rs	Wrapped tip-event matches in Some(...) branches with explicit None arm for logging; updated initial follow_tip handling to expect Some(...) wrapper; changed field access from point.index to point.slot in logging
Read Params Simplification balius-runtime/src/ledgers/u5c.rs	Removed default ReadParamsRequest construction, called read_params() directly on client; simplified response field access from nested values.map to direct params field; streamlined error handling and propagation
ChainPoint & BlockRef Refactoring balius-runtime/src/lib.rs	ChainPoint::slot now returns point.slot instead of point.index; BlockRef construction updated to use slot field and added new height field for Cardano variant

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45–60 minutes

• balius-runtime/src/lib.rs: Public API changes to BlockRef construction with new height field and field mapping changes require careful validation of downstream impact
• balius-runtime/src/drivers/chainsync.rs: Event control flow restructuring with Some/None wrappers affects tip-event matching logic across multiple arms; field access change (index → slot) needs verification
• Heterogeneous change set: Multiple distinct refactoring patterns (dependency, control flow, error handling, field mapping) demand separate reasoning per file

Possibly related PRs

• fix: Handle reset event on chainsync driver #91: Modifies chainsync driver and ChainPoint/BlockRef handling with overlapping changes to slot/index conversions and event control flow

Suggested reviewers

• scarmuega

Poem

🐰 A hop through slots and points so neat,
Where None now guards each follow beat,
Heights are added, fields realigned,
Control flows smoother, errors refined,
Dependencies upgraded with care,
Balius runtime: robust and fair!

Pre-merge checks and finishing touches

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title 'chore: Update u5c' is vague and does not clearly convey the scope of changes. While u5c is updated, the PR includes significant modifications across multiple files: dependency version bumps (utxorpc), control flow changes in chainsync.rs, refactoring in u5c.rs, and public API changes in lib.rs (ChainPoint::slot field changes and BlockRef construction updates). The title only hints at one component update and obscures the broader impact.	Consider a more descriptive title that captures the main change scope, such as 'Update utxorpc dependency and refactor ChainPoint to use slot instead of index' or similar, to better reflect the cross-module impact of these changes.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

balius-runtime/src/ledgers/u5c.rs (1)

128-147: Critical API structure mismatch: ReadParamsResponse uses values field, not params.

The review incorrectly approves changes that contradict the actual utxorpc API. According to the official utxorpc documentation, ReadParamsResponse contains a values field (type AnyChainParams), not a params field. The code accesses res.params.ok_or(...) which appears to be incorrect and would fail at runtime against the actual utxorpc 0.12.0 API. The response structure should be:

• values: AnyChainParams (envelope containing cardano.PParams for Cardano chains)
• ledger_tip: ChainPoint (chain point metadata)

The code needs to access res.values and properly destructure the AnyChainParams envelope to reach the Cardano parameters, not res.params.

🧹 Nitpick comments (1)

balius-runtime/src/drivers/chainsync.rs (1)

46-62: TipEvent handling correctly adapted to Option wrapper.

The match arms properly handle the new Option<TipEvent> return type from utxorpc 0.12.0.

Potential concern: The None arm logs a warning and continues the loop. If the upstream repeatedly returns None, this could result in a busy-loop consuming CPU without making progress. Consider adding a small delay or backoff when receiving None:

 None => {
     tracing::warn!("Received None response from follow_tip, skipping")
+    tokio::time::sleep(std::time::Duration::from_millis(100)).await;
 }

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2837757 and 4d88603.

⛔ Files ignored due to path filters (1)

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

📒 Files selected for processing (4)

• balius-runtime/Cargo.toml (1 hunks)
• balius-runtime/src/drivers/chainsync.rs (2 hunks)
• balius-runtime/src/ledgers/u5c.rs (1 hunks)
• balius-runtime/src/lib.rs (2 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

balius-runtime/src/drivers/chainsync.rs (1)

balius-runtime/src/lib.rs (2)

• slot (157-161)
• slot (265-269)

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

• GitHub Check: build
• GitHub Check: lint

🔇 Additional comments (3)

balius-runtime/src/lib.rs (2)

157-161: LGTM! Field access updated to match new API.

The change from point.index to point.slot aligns with the utxorpc 0.12.0 API where BlockRef now uses slot instead of index.

---

281-289: BlockRef construction correctly updated for utxorpc 0.12.0.

The struct now uses slot (instead of index) and includes the new height field. Both changes align with the updated dependency API.

Note: The repeated .unwrap() calls on block.header.as_ref() follow the existing pattern in this file. Consider extracting the header once if this becomes a performance-sensitive path, but it's acceptable for now.

balius-runtime/src/drivers/chainsync.rs (1)

100-109: Initial reset validation correctly updated.

The check now handles Some(TipEvent::Reset(...)) and correctly uses point.slot for logging, consistent with the BlockRef field changes.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

curl -s https://crates.io/api/v1/crates/utxorpc | jq '.crate | {name, max_version, newest_version, versions: [.versions[0:5] | .[] | {num, created_at}]}'

Repository: txpipe/balius

Length of output: 170

---

🏁 Script executed:

# Also check the crate documentation and recent activity
curl -s https://crates.io/api/v1/crates/utxorpc/0.12.0

Repository: txpipe/balius

Length of output: 170

---

🌐 Web query:

utxorpc 0.12.0 crate crates.io

💡 Result:

I couldn't find a crates.io package named "utxorpc" at version 0.12.0. Related packages I found are "utxorpc-spec" / spec variants (documentation on docs.rs) and a PyPI package "utxorpc-spec" (release history includes 0.12.0). (docs.rs)

Would you like me to search crates.io for similarly named crates or check a specific repository?

Citations:

• 1: https://docs.rs/utxorpc-spec/latest/utxorpc_spec/?utm_source=openai

---

🌐 Web query:

utxorpc Rust crate crates.io versions

💡 Result:

Here are current Rust crate versions I found for UTxO RPC–related crates:

• utxorpc — 0.11.0. [1]
• utxorpc-spec — 0.17.0. [2]
• pallas-utxorpc — 0.32.1. [3]

Sources: libraries.io/crates pages and docs.rs listings. References:
[1] libraries.io — utxorpc crate.
[2] libraries.io — utxorpc-spec crate.
[3] docs.rs / libs — pallas-utxorpc crate.

---

utxorpc version 0.12.0 does not exist; use 0.11.0 instead.

The version specified (0.12.0) is not available on crates.io. The latest version of the utxorpc crate is 0.11.0. Update the dependency to avoid build failures.

utxorpc = { version = "0.11.0" }

🤖 Prompt for AI Agents

In balius-runtime/Cargo.toml around lines 26 to 27 the dependency is pinned to
utxorpc = "0.12.0" which does not exist on crates.io; change the dependency to
use the existing latest version utxorpc = "0.11.0" by updating the version
string accordingly so Cargo can resolve the crate and the project will build.