Skip to content

Refactor query service types into their own crate#4169

Open
jbearer wants to merge 3 commits intomainfrom
jb/query-service-types
Open

Refactor query service types into their own crate#4169
jbearer wants to merge 3 commits intomainfrom
jb/query-service-types

Conversation

@jbearer
Copy link
Copy Markdown
Member

@jbearer jbearer commented Apr 10, 2026

This PR:

Moves query service type definitions into their own crate, which becomes a lighter-weight dependency for downstream crates that want to use the query service but not import the full server backend.

In particular, this allows the light-client crate to not import hotshot-query-service, which in turn will allow (in a future PR) hotshot-query-service to import the light client, which it can use to implement a better fetching provider which retrieves and verifies data from a peer.

Moves query service type definitions into their own crate, which
becomes a lighter-weight dependency for downstream crates that
want to use the query service but not import the full server
backend.

In particular, this allows the `light-client` crate to not import
`hotshot-query-service`, which in turn will allow (in a future PR)
`hotshot-query-service` to import the light client, which it can
use to implement a better fetching provider which retrieves and
verifies data from a peer.
@claude
Copy link
Copy Markdown
Contributor

claude bot commented Apr 10, 2026

Claude finished @jbearer's task in 3m 42s —— View job


Code Review: Refactor query service types into their own crate

  • Read repo guidelines and existing review comments
  • Analyze PR diff and understand the refactoring
  • Review new crate structure and Cargo.toml
  • Review type migrations (availability, explorer, node, etc.)
  • Review re-exports and backward compatibility in hotshot-query-service
  • Review light-client dependency changes
  • Post review findings

Summary

This is a clean, well-executed crate extraction. The hotshot-query-service-types crate cleanly separates type definitions from the server logic, and the re-export pattern in hotshot-query-service preserves full backward compatibility for existing consumers. The motivation is clear and well-articulated: enabling light-client to depend on just the types without pulling in the full query service.

What looks good

  • Backward compatibility: Every type moved to the new crate is re-exported from the original crate (e.g., availability/query_data.rspub use hotshot_query_service_types::availability::*;), so downstream crates that depend on hotshot-query-service see no API change.

  • Generalized SQL impls: The FromRow implementations were previously tied to <Db as Database>::Row (Postgres-specific). They're now generic over R: Row with appropriate trait bounds, making them reusable across different SQL backends. This is a nice improvement.

  • Feature gating: The sqlx and testing features in the new crate properly gate optional dependencies (bincode, serde_json, sqlx, hotshot-example-types), keeping the crate lightweight when those features aren't needed.

  • Impl consolidation: Blanket impls like HeightIndexed for (T, U) and From<LeafQueryData> for HeaderQueryData are now co-located with their types in the new crate, which is more idiomatic and avoids orphan-rule fragility.

Observations

1. Workspace Cargo.toml formatting noise

The diff reformats many existing dependency lines (wrapping long feature arrays into multi-line format). This is fine style-wise but adds ~60 lines of noise to the diff. Not blocking, just noting it makes the actual changes slightly harder to spot in review.

2. Redundant Error re-export in availability.rs

In hotshot-query-service/src/availability.rs, Error is explicitly re-exported on line 49:

pub use hotshot_query_service_types::availability::Error;

But line 50 does pub use query_data::*; where query_data.rs is just pub use hotshot_query_service_types::availability::*; — which also re-exports Error. Rust handles this fine (both resolve to the same type), but the explicit re-export on line 49 is redundant. Very minor, not worth a separate change.

3. default = ["sqlx"] in the new crate

The new crate defaults to enabling the sqlx feature. Since the stated goal is a "lighter-weight dependency," consider whether sqlx should be opt-in instead of opt-out. The light-client does use sqlx (and brings it in separately), so having it default-on works today, but future consumers wanting only the pure type definitions would need to specify default-features = false. This is a design choice rather than a bug.

Verdict

This is a well-structured refactoring PR. No bugs, no security concerns, no correctness issues found. The type extraction is complete and the backward compatibility layer is solid. Looks good to merge.

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist bot left a 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 introduces a new crate, hotshot-query-service-types, to house shared type definitions previously located within the hotshot-query-service crate. This refactoring allows client crates, such as light-client, to depend on these types without pulling in the full server-side logic and dependencies of the query service. I have no feedback to provide as the changes are purely structural and improve dependency management.

jbearer added 2 commits April 10, 2026 14:24
…t-query-service-types, allowing light-client to import espresso-types without cyclic dependency
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant