Fix Cargo.lock mismatch causing deploy failure#61
Conversation
Remove stale tracing dep from rain_orderbook_subgraph_client that was incorrectly added from a dirty submodule during PR #58.
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (1)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ 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 |
Motivation
The deploy workflow has been failing since PR #58 was merged. The nix build runs
cargo check --release --lockedwhich rejects any mismatch betweenCargo.lockand the actual dependency graph. The root cause is a staletracingdependency listed underrain_orderbook_subgraph_clientinCargo.lockthat doesn't exist in the submodule'scrates/subgraph/Cargo.toml.This was introduced during PR #58 development, where the local submodule had a dirty
Cargo.toml(withtracinginjected from a priorraindex-preluderun on an older submodule version). The regeneratedCargo.lockcaptured that phantom dependency. In CI, the submodule checks out clean, so--lockedfails.Solution
Remove the single stale
tracingentry fromrain_orderbook_subgraph_client's dependency list inCargo.lock. Verified locally thatcargo check --lockedpasses after this change with a cleanly initialized submodule.Checks
By submitting this for review, I'm confirming I've done the following: