chore: bump solana deps #43
Conversation
WalkthroughReplaced Anchor serialization with Borsh across many types; migrated Solana crate imports to new solana_* crates and bumped Solana-related dependencies; added a new public Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Monitor as Monitor
participant RPC as RPC / Account Source
participant V1 as v1_tree_accounts
participant Parser as Ingester Parser
Note right of V1: new module exposing V1 discriminators & zero-copy tree()
Monitor->>RPC: fetch account bytes
RPC-->>Monitor: account bytes
Monitor->>V1: check_discriminator(data)
alt discriminator == V1
V1-->>Monitor: from_account_bytes -> {metadata, tree_bytes}
Monitor->>V1: tree() -> zero-copy view
V1-->>Monitor: tree handle (height/root/seq/next_index)
else not V1
Monitor->>Monitor: use BatchedMerkleTreeAccount.from_account_bytes
end
Monitor->>Parser: provide TreeAccountData (includes tree-derived fields)
Parser->>Parser: convert tree bytes -> Solana Pubkey for lookups/logging
Parser->>DB: lookup by Pubkey bytes / emit warnings or queue missing
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Poem
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/common/typedefs/unsigned_integer.rs (1)
80-91: BringRead/Writeinto scope so this still compiles.
reader.read_exactandwriter.write_allrely on theRead/Writetraits being in scope; without that, the compiler raises E0599 for missing methods. Please call the trait methods with fully-qualified paths (or import the traits).- reader.read_exact(&mut buffer)?; + std::io::Read::read_exact(reader, &mut buffer)?; @@ - writer.write_all(&self.0.to_le_bytes()) + std::io::Write::write_all(writer, &self.0.to_le_bytes())
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (11)
Cargo.toml(1 hunks)src/api/method/get_multiple_new_address_proofs.rs(1 hunks)src/common/typedefs/serializable_pubkey.rs(3 hunks)src/common/typedefs/token_data.rs(3 hunks)src/common/typedefs/unsigned_integer.rs(2 hunks)src/ingester/parser/indexer_events.rs(9 hunks)src/ingester/parser/tx_event_parser.rs(2 hunks)src/ingester/parser/tx_event_parser_v2.rs(6 hunks)src/monitor/mod.rs(1 hunks)src/monitor/tree_metadata_sync.rs(5 hunks)src/monitor/v1_tree_accounts.rs(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (4)
src/ingester/parser/tx_event_parser.rs (1)
src/ingester/parser/tree_info.rs (1)
get_by_pubkey(28-65)
src/common/typedefs/serializable_pubkey.rs (2)
src/common/typedefs/unsigned_integer.rs (2)
deserialize(31-63)deserialize(67-78)src/ingester/parser/state_update.rs (2)
new(115-117)from(81-87)
src/ingester/parser/tx_event_parser_v2.rs (1)
src/common/typedefs/serializable_pubkey.rs (6)
from(96-98)from(102-104)from(108-110)from(114-116)from(120-122)from(136-138)
src/monitor/tree_metadata_sync.rs (1)
src/monitor/v1_tree_accounts.rs (1)
check_discriminator(53-67)
⏰ 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: Run tests
🔇 Additional comments (3)
src/monitor/tree_metadata_sync.rs (3)
11-14: LGTM! Clean import consolidation.The consolidated import from
crate::monitor::v1_tree_accountsimproves code organization by centralizing V1 tree account types, discriminator constants, and utility functions in one place. All imported items are actively used throughout the file.
188-216: Excellent refactoring to higher-level abstractions.The changes improve maintainability by:
- Using a generic
check_discriminatorfunction with explicit discriminator constants- Replacing low-level zero-copy byte manipulation with the
tree()accessor method- Maintaining proper error handling while simplifying the code
The deserialization correctly starts at byte 8 (after the 8-byte discriminator), and the data extraction from the
merkle_treeobject is clean and straightforward.
218-246: Consistent refactoring pattern with correct address tree handling.The changes mirror the improvements in
process_v1_state_accountwhile correctly handling the differences in address tree structure:
- Uses the same generic
check_discriminatorapproach withADDRESS_MERKLE_TREE_DISCRIMINATOR- Applies the
tree()accessor pattern consistently- Correctly accesses nested
indexed_tree.merkle_treefields (lines 240-243)- Uses an appropriate error message: "Failed to parse indexed merkle tree"
The refactoring maintains correctness while improving code clarity.
| impl borsh::BorshSerialize for SerializablePubkey { | ||
| fn serialize<W: std::io::Write>(&self, writer: &mut W) -> Result<(), std::io::Error> { | ||
| writer.write_all(&self.0.to_bytes()) | ||
| } |
There was a problem hiding this comment.
write_all needs the Write trait in scope here.
writer.write_all will not compile until the Write trait is imported or the call is fully qualified. Please update the call accordingly.
- writer.write_all(&self.0.to_bytes())
+ std::io::Write::write_all(writer, &self.0.to_bytes())📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| impl borsh::BorshSerialize for SerializablePubkey { | |
| fn serialize<W: std::io::Write>(&self, writer: &mut W) -> Result<(), std::io::Error> { | |
| writer.write_all(&self.0.to_bytes()) | |
| } | |
| impl borsh::BorshSerialize for SerializablePubkey { | |
| fn serialize<W: std::io::Write>(&self, writer: &mut W) -> Result<(), std::io::Error> { | |
| std::io::Write::write_all(writer, &self.0.to_bytes()) | |
| } |
🤖 Prompt for AI Agents
In src/common/typedefs/serializable_pubkey.rs around lines 53 to 56, the call to
writer.write_all(...) requires the Write trait to be in scope; either add use
std::io::Write; at the top of the file or change the call to the fully-qualified
form std::io::Write::write_all(writer, &self.0.to_bytes()); make that single
change so the serialize method compiles without altering the method signature.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
src/monitor/v1_tree_accounts.rs (1)
53-63: Critical: Same double-skip issue in address account.Line 61 has the identical double-skip bug as in
StateMerkleTreeAccount. After deserializing metadata, the cursor is already positioned at the tree data, so the additionalsize_of::<MerkleTreeMetadata>()skip corrupts the tree bytes.Apply this fix:
pub fn from_account_bytes(data: &[u8]) -> Result<Self, std::io::Error> { check_discriminator(data, &ADDRESS_MERKLE_TREE_DISCRIMINATOR)?; let mut cursor = &data[8..]; let metadata = MerkleTreeMetadata::deserialize(&mut cursor) .map_err(|e| std::io::Error::new(std::io::ErrorKind::InvalidData, e.to_string()))?; Ok(Self { metadata, - tree_bytes: cursor[size_of::<MerkleTreeMetadata>()..].to_vec(), + tree_bytes: cursor.to_vec(), }) }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (7)
Cargo.toml(2 hunks)src/ingester/parser/indexer_events.rs(9 hunks)src/ingester/parser/state_update.rs(1 hunks)src/ingester/parser/tx_event_parser_v2.rs(6 hunks)src/ingester/persist/spend.rs(1 hunks)src/monitor/tree_metadata_sync.rs(3 hunks)src/monitor/v1_tree_accounts.rs(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- src/ingester/parser/state_update.rs
🧰 Additional context used
🧬 Code graph analysis (3)
src/ingester/parser/tx_event_parser_v2.rs (2)
src/ingester/parser/state_update.rs (3)
parse(397-398)parse(511-512)from(81-87)src/common/typedefs/serializable_pubkey.rs (6)
from(96-98)from(102-104)from(108-110)from(114-116)from(120-122)from(136-138)
src/monitor/v1_tree_accounts.rs (1)
src/monitor/mod.rs (1)
mem(181-181)
src/monitor/tree_metadata_sync.rs (1)
src/monitor/v1_tree_accounts.rs (2)
from_account_bytes(26-35)from_account_bytes(54-63)
⏰ 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: Run tests
🔇 Additional comments (14)
src/ingester/persist/spend.rs (1)
8-8: LGTM! Import path updated correctly.The import path change from
light_compressed_account::indexer_event::eventtolight_event::eventaligns with the newlight-eventdependency structure in Cargo.toml.src/ingester/parser/tx_event_parser_v2.rs (3)
18-21: LGTM! Helper function centralizes pubkey conversion.The
to_light_pubkeyhelper improves consistency and readability by centralizing the Solana Pubkey to LightPubkey conversion logic.
28-32: LGTM! Consistent use of the conversion helper.The code correctly applies the
to_light_pubkeyhelper for both single pubkeys and nested vectors, ensuring uniform conversion across all account structures.
52-83: LGTM! Simplified pubkey handling.Removing the
.into()conversions indicates that the types are now directly compatible. Lines 52, 72, and 83 correctly use direct field assignment forowner,pubkey, andpubkey_array.src/monitor/tree_metadata_sync.rs (2)
184-201: LGTM! Properly delegates to v1_tree_accounts module.The refactored
process_v1_state_accountcorrectly usesStateMerkleTreeAccount::from_account_bytesfollowed by.tree(), with appropriate error handling and context.
203-224: LGTM! Address account processing follows the same pattern.The
process_v1_address_accountfunction mirrors the state account processing pattern, ensuring consistency in how V1 tree accounts are handled.src/monitor/v1_tree_accounts.rs (3)
37-42: LGTM! Zero-copy tree accessor is correct.The
tree()method properly creates a zero-copy view fromtree_byteswith appropriate error conversion.
65-72: LGTM! Indexed tree accessor follows the same pattern.The indexed merkle tree accessor correctly mirrors the state tree implementation.
74-89: LGTM! Discriminator validation is robust.The
check_discriminatorfunction properly validates length and discriminator match with clear error messages.src/ingester/parser/indexer_events.rs (3)
3-5: LGTM! Imports updated for Borsh migration.The import changes correctly replace Anchor dependencies with Borsh traits and the new
light_eventmodule, aligning with the dependency updates in Cargo.toml.
7-86: LGTM! Comprehensive Borsh migration.All struct and enum derives have been systematically updated from Anchor traits to
BorshSerialize/BorshDeserialize. The addition of thedata_hashfield on Line 85 inCompressedAccountDataappears to be part of the data model update accompanying this serialization migration.
92-180: LGTM! Event types migrated consistently.All event-related types (
MerkleTreeEvent,PathNode,ChangelogEvent,NullifierEvent,IndexedMerkleTreeEvent,BatchEvent) have been updated with Borsh derives, maintaining consistency across the entire event system.Cargo.toml (2)
83-91: Verify that git-based dependencies are intentional.All
light-*dependencies have been migrated from versioned crates to git-based references with a pinned rev. While this provides access to the latest changes, it can impact build reproducibility and CI performance.Confirm that using git-based dependencies is intentional for this phase. If these changes are available in published crates, consider switching back to versioned dependencies for better build stability and performance.
79-91: LGTM! Dependencies updated consistently.The removal of
anchor-lang, addition oflight-eventandlight-indexed-merkle-tree, and the consistent use ofdefault-features = falseacross all light-* dependencies align well with the Borsh migration goals. All git dependencies use the same rev (40736887082f6f879ee73c77005adabd36ead5b6), ensuring version consistency.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (1)
Cargo.toml(4 hunks)
🔇 Additional comments (4)
Cargo.toml (4)
77-86: Migration to Solana 3.x is complete and verified.The Solana 1.x → 3.x upgrade has been successfully implemented:
- Legacy imports eliminated: No
solana_sdkreferences remain; codebase fully migrated to modular 3.x crates.- Module structure verified:
solana_client,solana_account,solana_signature,solana_clock,solana_transaction, andsolana_transaction_statusimports confirmed in use across source and tests.- Features enabled and active:
solana-pubkeyfeatures["serde", "borsh"]are explicitly configured and actively used throughout (serde_json serialization in API layer, BorshSerialize/BorshDeserialize in indexer events).- v1_tree_accounts module: Fully implemented and correctly integrated (
src/monitor/v1_tree_accounts.rs, properly imported and used).- API compatibility confirmed: RpcClient methods, VersionedTransaction decoding, and Account types all compatible with 3.x versions.
No breaking changes detected; migration appears complete and functional.
44-45: Dual Borsh versions appear intentional for Solana v3 migration—verify and document the asymmetric implementation.The pattern of using
borsh v0.10for serialization andborsh v1.5for deserialization inSerializablePubkey(lines 34–45) is an isolated, deliberate workaround forsolana-pubkey v3.0.0, which depends on borsh v1.5. However, the implementation risks round-trip serialization failures and lacks documentation:
- No comments explain why deserialization delegates to
SolanaPubkey as BorshDeserialize1while serialization uses manual byte writing- No explicit round-trip tests verify
SerializablePubkeyserialization works correctly in nested structures- The asymmetric approach bypasses Borsh safety guarantees and could break if
solana_pubkeychanges its byte formatConfirm this pattern is intentional, document it with a comment explaining the Solana v3 compatibility requirement, and add serialization round-trip tests.
88-96: No critical issues found with the current feature configuration.The original concern about "aggressive disabling" of
default-featuresis not substantiated:
- light-compressed-account v0.6.0 only defaults to the "alloc" feature, which is not required by the type imports (TreeType, QueueType) used throughout the codebase.
- light-zero-copy recent versions show no features enabled by default, making
default-features = falseredundant or intentional for consistency.- light-concurrent-merkle-tree has no features enabled by default; the available features (pinocchio, solana, solana-program-error) are not imported or used in the codebase.
- light-hasher explicitly specifies
["poseidon", "keccak", "sha256"]features, which directly match the hash functions and Poseidon imports found in the code.The codebase contains no conditional compilation or feature gates (
cfgdirectives), and the active API usage (zero_copy structs, type enums, hash functions) relies on core functionality—not optional features. The configuration is sound.
95-96: Upgrade verification complete—v4 APIs already integrated and functional.The codebase has already migrated to the v4 API correctly:
- Tree API compatibility: All merkle tree operations use v4-compatible types (
RawIndexedElement,from_bytes_zero_copy,from_bytes_copy) and methods (.append(),.sequence_number(),.next_index(),.height,.roots.capacity(),.is_empty()).- Serialization compatibility verified: Integration tests confirm tree deserialization from existing data works (
merkle_tree_deserialization_from_devnet,persist_indexed_tree_updates).- light_event 0.1.1 integrated:
BatchNullifyContextandNewAddresstypes are properly imported and used across event parsing and persistence modules.Note: Cargo.lock specifies
light-concurrent-merkle-treev4.0.1, which is not currently published on crates.io (only 4.0.0 is available). Verify whether this version comes from a private registry or is a development dependency, and confirm it's available in your build environment.
| yellowstone-grpc-client = "10.1.1" | ||
| yellowstone-grpc-proto = "10.1.1" |
There was a problem hiding this comment.
🧩 Analysis chain
Verify Yellowstone gRPC client/proto v10.1.1 API compatibility.
Yellowstone gRPC dependencies have jumped from 1.15.0/1.14.0 to 10.1.1—a major version increase. This suggests either:
- A versioning reset in the upstream project.
- Significant API/protocol changes requiring code adaptation.
Confirm that your gRPC client code, subscription handlers, and message parsing are compatible with the v10.1.1 API surface. Check the release notes or changelog for breaking changes.
🏁 Script executed:
#!/bin/bash
# Description: Verify Yellowstone gRPC API usage is compatible with v10.1.1.
# Search for yellowstone gRPC client usage
rg -n 'yellowstone_grpc|GrpcClient|UpdateOnDemand|AccountUpdate' --type rust | head -20
# Check for any hardcoded version assumptions in code
rg -n '10\\.1\\.1|1\\.15|1\\.14' --type rust --type tomlLength of output: 653
🏁 Script executed:
#!/bin/bash
# Examine the grpc.rs file for subscription handlers and message parsing details
cat src/ingester/fetchers/grpc.rs | head -100Length of output: 4503
🏁 Script executed:
#!/bin/bash
# Look for subscription handlers and how messages are processed
rg -n 'subscribe|Subscribe|on_update|OnUpdate|handle' --type rust src/ingester/fetchers/grpc.rs -A 3Length of output: 2119
🌐 Web query:
Yellowstone gRPC v10.1.1 changelog breaking changes
💡 Result:
I couldn't find a published changelog entry that lists breaking changes specifically for Yellowstone gRPC v10.1.1. The project changelog (shows up through v10.0.1 and earlier breaking-change notes) and the crate page for v10.1.1 are here for reference:
- Project changelog (shows breaking notes up to v10.0.1). [1]
- docs.rs listing for yellowstone-grpc-client 10.1.1. [2]
- GitHub releases/tags for the rpcpool/yellowstone-grpc repo (latest tags include v10.0.1 variants). [3]
If you want, I can:
- search GitHub tags/commits for the v10.1.1 tag or commit and extract any breaking-change notes, or
- open the v10.1.1 crate/source to compare public API/proto changes and list breaking changes.
Which would you prefer?
🌐 Web query:
Yellowstone gRPC GitHub releases v10.1.1 rpcpool
💡 Result:
I couldn't find a v10.1.1 release for rpcpool/yellowstone-grpc on GitHub. The repository's releases page lists tags up to v10.0.1 (and v9.1.0 as the latest shown). [1][2]
Sources:
- rpcpool/yellowstone-grpc releases page. [1]
- rpcpool/yellowstone-grpc repository README. [2]
🌐 Web query:
yellowstone-grpc-proto 10.1.1 crates.io API documentation
💡 Result:
I couldn't find published docs for version 10.1.1, but the nearest available API docs and sources are:
- Docs (API) on docs.rs (v10.1.0): https://docs.rs/crate/yellowstone-grpc-proto/10.1.0. [1]
- Official protobuf source (proto files / repo): https://github.com/rpcpool/yellowstone-grpc/tree/master/yellowstone-grpc-proto/proto. [2]
If you specifically need 10.1.1 API docs, do you want me to: (A) check crates.io for that exact version and try to open its docs, or (B) fetch the 10.1.1 crate sources from crates.io/GitHub so I can generate or inspect the API surface?
---
🏁 Script executed:
```shell
#!/bin/bash
# Check if Cargo.lock exists and what versions are actually locked
if [ -f Cargo.lock ]; then
echo "=== Cargo.lock entries for yellowstone ==="
rg -n 'name = "yellowstone' Cargo.lock -A 2
else
echo "No Cargo.lock found"
fi
Length of output: 308
🌐 Web query:
crates.io yellowstone-grpc-client 10.1.1 version
💡 Result:
Yes — version 10.1.1 of yellowstone-grpc-client is published (docs/metadata available). [1][2]
Sources:
- docs.rs page for yellowstone-grpc-client 10.1.1. [1]
- versions/metadata listing for the crate. [2]
🌐 Web query:
crates.io yellowstone-grpc-proto 10.1.1 version
💡 Result:
There is no yellowstone-grpc-proto v10.1.1 on crates.io — the latest published crate version is 10.1.0 (as shown on docs.rs). [1][2]
Sources:
- yellowstone-grpc-proto (docs.rs) — latest / 10.1.0. [1]
- rpcpool/yellowstone-grpc releases (GitHub) — tags/releases show v10.0.1 series; no v10.1.1 for the proto crate. [2]
🏁 Script executed:
#!/bin/bash
# Extract the exact dependency specification from Cargo.toml
rg -n 'yellowstone-grpc' Cargo.toml -A 1 -B 1Length of output: 106
🌐 Web query:
yellowstone-grpc-proto 10.1.1 yanked deprecated version status
💡 Result:
I can't find any record that yellowstone-grpc-proto v10.1.1 exists or was yanked. The published crate documentation and index show v10.1.0 as the latest release of yellowstone-grpc-proto. [1][2]
Sources:
- docs.rs listing for yellowstone-grpc-proto (latest / 10.1.0). [1]
- docs.rs page specifically for 10.0.1 / 10.1.0 (package docs). [2]
Fix Cargo.toml: yellowstone-grpc-proto v10.1.1 does not exist on crates.io.
yellowstone-grpc-proto v10.1.1 is not published on crates.io; the latest version is 10.1.0. While yellowstone-grpc-client v10.1.1 exists, the proto dependency in Cargo.toml (line 129) is unresolvable. Update yellowstone-grpc-proto = "10.1.1" to "10.1.0" to match the available crate version, or verify if a different proto version is intended.
🤖 Prompt for AI Agents
In Cargo.toml around lines 128 to 129, the dependency declaration lists
yellowstone-grpc-proto = "10.1.1" which is not published on crates.io; change
that version to "10.1.0" (or to the intended published version) so the proto
crate resolves, ensuring the client and proto versions remain compatible.
Overview
Testing
Summary by CodeRabbit
New Features
Bug Fixes
Chores
Tests