-
Notifications
You must be signed in to change notification settings - Fork 8
deps: upgrade to v1.10.1 #106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Claude finished @chatton's task —— View job PR Review: deps: upgrade to v1.10.1I've completed a comprehensive review of this Reth v1.10.1 upgrade PR. Here's my detailed analysis: SummaryThis is a well-executed dependency upgrade from Reth v1.8.4 to v1.10.1 with proper code adaptations. The changes are primarily focused on API compatibility updates rather than fundamental architectural changes. ✅ StrengthsDependency Management
Code Quality
Architecture Compliance
|
Summary of ChangesHello @chatton, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request focuses on a significant dependency upgrade, moving the project's core Reth framework to version Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request upgrades several key dependencies, most notably reth from v1.8.4 to v1.10.1, along with revm and alloy. The majority of the code changes are adaptations to the new APIs of these upgraded dependencies. The OTLP tracing initialization has also been refactored to be more robust and configurable via environment variables.
My review focuses on the new tracing logic and general maintainability. I've identified a couple of issues in the tracing initialization: one that could prevent tracing from being enabled at all, and another related to non-compliance with the OpenTelemetry specification for disabling the SDK. I've also pointed out an outdated comment in Cargo.toml that should be updated to reflect the new dependency version. The rest of the changes appear to be correct adaptations to the upstream API changes.
| if std::env::var("OTEL_SDK_DISABLED").as_deref() == Ok("false") { | ||
| init_otlp_tracing(); | ||
| init_tracing(); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The init_tracing() function is only called if OTEL_SDK_DISABLED is explicitly set to "false". If the environment variable is not set, no tracing will be initialized at all, which is likely not the intended behavior. The init_tracing function itself correctly handles whether to enable OTLP based on environment variables. Therefore, the conditional check in main is redundant and can lead to no tracing being configured. init_tracing() should be called unconditionally.
init_tracing();| authors = ["Evolve Stack Contributors"] | ||
|
|
||
| [workspace.dependencies] | ||
| # Reth dependencies - Using v1.8.4 stable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| // disabled if OTEL_SDK_DISABLED is set to anything other than "false" | ||
| if std::env::var("OTEL_SDK_DISABLED").is_ok_and(|v| v != "false") { | ||
| return None; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current implementation for checking OTEL_SDK_DISABLED is not fully compliant with the OpenTelemetry specification. The spec states that the SDK should be disabled only if OTEL_SDK_DISABLED is set to true (case-insensitive), and any other value should be ignored (meaning the SDK is not disabled). The current logic disables the SDK for any value other than "false". This should be corrected to only disable for "true".
| // disabled if OTEL_SDK_DISABLED is set to anything other than "false" | |
| if std::env::var("OTEL_SDK_DISABLED").is_ok_and(|v| v != "false") { | |
| return None; | |
| } | |
| // disabled if OTEL_SDK_DISABLED is set to "true" (case-insensitive) | |
| if std::env::var("OTEL_SDK_DISABLED").map_or(false, |v| v.eq_ignore_ascii_case("true")) { | |
| return None; | |
| } |
Description
Type of Change
WIP: creating PR to build docker images
Related Issues
Fixes #(issue)
Checklist
Testing
Additional Notes