refactor(utils/crates-io): add more metadata, less patches, account for publishing rate limits

[StackOverflowExcept1on]

Closes #5601

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! 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 performs a comprehensive refactoring of the RPC architecture by decomposing the monolithic ethexe-rpc crate into client, common, and server-specific modules. Alongside this architectural change, the PR standardizes package metadata across the workspace to ensure consistent crate publishing. Finally, the crates-io management utility has been upgraded to support better metadata validation and handle publishing rate limits, facilitating more reliable release cycles.

Highlights

• RPC Layer Refactoring: Split the existing ethexe-rpc crate into three specialized components: ethexe-rpc-client, ethexe-rpc-common, and ethexe-rpc-server to improve modularity.
• Workspace Metadata Standardization: Updated Cargo.toml files across the entire workspace to include standardized metadata, including keywords, categories, and rust-version, to improve crate discoverability and maintainability.
• Crate Renaming: Renamed core-processor to gear-core-processor throughout the repository to resolve naming conflicts and align with the naming convention.
• Publishing Utility Improvements: Enhanced the crates-io utility with robust metadata validation, rate-limit handling, and improved CLI feedback for publishing operations.

Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the 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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. 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.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request reorganizes the ethexe-rpc crate by splitting it into three separate crates: ethexe-rpc-common, ethexe-rpc-client, and ethexe-rpc-server, updating dependencies and imports across the codebase accordingly. It also enhances the crates-io publishing utility to enforce category and keyword checks and prompt for restoring local changes on failure. Feedback on these changes highlights a potential infinite loop in the interactive restore prompt when EOF is reached on stdin, as well as a missing rate-limiting implementation for crates.io publishing that was left as a TODO despite being mentioned in the PR title.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[StackOverflowExcept1on]

@claude opus review

[claude]

Claude finished @StackOverflowExcept1on's task in 2m 35s —— View job

---

Code Review

This PR splits the monolithic ethexe-rpc crate into ethexe-rpc-common / -client / -server, standardizes publishing metadata (keywords/categories/rust-version) across the workspace, renames core-processor → gear-core-processor, and adds metadata validation + crates.io rate-limit handling to the crates-io utility. Overall the change is well-structured and the RPC split is clean — client and server traits stay in sync via shared types in ethexe-rpc-common. No blocking issues found.

A useful note up front: both of the Gemini review comments are already resolved on this branch. The EOF handling exists at utils/crates-io/src/main.rs:99-102, and the rate-limit TODO is now a full implementation in publisher.rs (CratesIoRateLimiter). Those threads can be dismissed.

---

Findings

medium — Rate limiter is purely count-based and may serialize CI for a very long time

File: utils/crates-io/src/publisher.rs lines 72-108

PublishRateLimitCounter::satisfy sleeps refill_interval + 30s on every publish once publishes >= burst, and never resets. The logic is correct and safely conservative (it can only over-wait, never under-wait, since real elapsed time only adds tokens). But the consequences are worth flagging:

• New crates: burst 5, then 10.5 min per crate. This PR alone adds several new crates (ethexe-rpc-common, ethexe-rpc-client, …), and the publish job iterates all PACKAGES. With N new crates beyond 5, the job blocks for (N-5) × 10.5 min. That's expected given crates.io limits, but make sure the CI publish job timeout accommodates it.
• It ignores the wall-clock time cargo publish itself consumes (during which tokens refill), so it will frequently wait longer than strictly necessary. Acceptable as a safety tradeoff, just not optimal.
• The counter starts at 0 assuming a full burst is available. If a prior/retried CI run already consumed crates.io tokens, the first few publishes here could still hit the real limit. Inherent and hard to avoid — worth a comment acknowledging it.

low — InvalidOwners falls through to new-crate handling

File: utils/crates-io/src/publisher.rs lines 254-261

The PackageStatus::InvalidOwners arm is commented out (pending the gear-core-processor ownership transfer TODO), so is_published stays false. Downstream that means an already-published-but-mis-owned crate is rate-limited as a new crate and add_owner is attempted on it (lines 375-380). Harmless given the current TODO state, but worth a comment so it isn't forgotten when ownership is fixed.

low — Stale core_processor:: strings after the rename

File: vara/pallets/gear/src/benchmarking/utils.rs lines 223-270

Error-message string literals still read "core_processor::precharge_for_* failed". Purely cosmetic (not a build issue), but inconsistent with the new gear_core_processor crate name. Fix this →

---

Things that look correct

• Trait parity: client/server method names, namespaces, and subscription item types match (Program, Injected with item = SignedTxReceipt, subscribeBestState with item = ProgramBestState). Shared response types live once in ethexe-rpc-common, no duplication.
• Workspace wiring: ethexe/rpc is correctly excluded while the three subcrates are added as explicit members; the core-processor workspace alias was removed and the rename propagated through Cargo.tomls.
• Metadata validation in build() mirrors crates.io rules accurately (≤5 categories against the allow-list, ≤5 keywords, ≤20 chars, alphanumeric-start, allowed charset).
• readme = "README.md" was only added to protocol/core, and that file exists — so cargo publish won't fail on a missing readme.

One minor observation: RPC_VERSION is now defined independently in both the client (env!("CARGO_PKG_VERSION") of ethexe-rpc-client) and the server. They stay equal only because both inherit version.workspace = true. That's fine today; just be aware a client-vs-server version handshake relies on that invariant.

---

• Gather context (diff, key files)
• Review crates-io utility changes
• Review RPC split (client/common/server)
• Review metadata/renaming changes
• Post review
  · branch av/crates-io-refactoring

[StackOverflowExcept1on]

@breathx