Allow defining "include" and "exclude" filters on selections in query

[JonoPrest]

Summary by CodeRabbit

• New Features

  • More flexible nested filtering for blocks, logs, transactions, and traces with include/exclude and richer filter fields.
  • Fine-grained field selection and join-mode controls for queries.

• Tests

  • Added comprehensive backward-compatibility tests for old/new query formats.

• Chores

  • Package version bumps and added test dev-dependencies.
  • CI workflow formatting and added rustfmt/clippy to linting.

[coderabbitai]

Walkthrough

Refactors selection/filter types by introducing a generic Selection and concrete *Filter structs, adds From conversions, updates client usage to construct selections via .from(...), bumps package versions, enhances CI linting, and adds backward-compatibility tests for deserialization and round-trip serialization. (47 words)

Changes

Cohort / File(s)	Summary
CI workflow refinement .github/workflows/ci.yaml	Reformat step indentation and grouping; add rustfmt and clippy to lint job; no changes to executed commands.
Net-types public API & serialization hypersync-net-types/src/lib.rs	Add generic Selection<T> (with From<T>), introduce BlockFilter, LogFilter, TransactionFilter, TraceFilter and type aliases (BlockSelection, LogSelection, TransactionSelection, TraceSelection); update Query, FieldSelection, and JoinMode serialization/skipping logic and helper is_default.
Backward compatibility tests hypersync-net-types/tests/backward_compatibility.rs	New tests verifying deserialization of old JSON formats into new selection/filter structures and round-trip JSON equality checks.
Client code updates hypersync-client/src/preset_query.rs, hypersync-client/tests/api_test.rs	Client and tests now construct selections via LogSelection::from(LogFilter { ... }) and TransactionSelection::from(TransactionFilter { ... }); added imports for LogFilter/TransactionFilter.
Manifests & versions hypersync-net-types/Cargo.toml, hypersync-client/Cargo.toml	Bump hypersync-net-types 0.10.0 → 0.11.0-rc.1 and add dev-deps serde_json, pretty_assertions; bump hypersync-client 0.19.0 → 0.20.0-rc.1 and update dependency to hypersync-net-types = "0.11".

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant NetTypes
    participant Server

    rect rgb(240,248,255)
    note left of Client: Build query using filters
    Client->>NetTypes: Create TransactionFilter / LogFilter
    Client->>NetTypes: TransactionSelection::from(TransactionFilter) \nLogSelection::from(LogFilter)
    end

    rect rgb(245,255,240)
    note left of Client: Compose Query
    Client->>NetTypes: Insert Selection(s) into Query
    end

    rect rgb(255,250,240)
    note left of Client: Serialize & send
    Client->>Server: POST /query (serialized Query JSON)
    Server-->>Client: Query response
    end

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Possibly related PRs

• Improve Get Event join logic #76 — Related modifications to selection/filter representations and client consumption patterns that intersect with the Selection/Filter changes here.

Suggested reviewers

• JasoonS

Poem

🐇✨ I nibble filters, tuck them neat inside,
From-traits sewn tight so old JSON can ride.
CI polishes lint while tests clap a paw,
Round-trip whispers, "backward safe" — huzzah! 🥕

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The pull request title "Allow defining "include" and "exclude" filters on selections in query" accurately captures the core objective of the changeset. The main contribution is the refactoring of the selection system in hypersync-net-types to introduce a generic Selection wrapper with both include and exclude (optional) fields, along with corresponding filter types (BlockFilter, LogFilter, TransactionFilter, TraceFilter). This enables users to define more flexible filters with both include and exclude capabilities. While the PR also includes version bumps, CI workflow formatting, and backward compatibility tests, the title appropriately focuses on the primary feature change.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch jp/hack-negative-queries

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 35ca036 and fff0fbd.

📒 Files selected for processing (2)

• hypersync-client/Cargo.toml (2 hunks)
• hypersync-net-types/Cargo.toml (2 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• hypersync-client/Cargo.toml

⏰ 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: test_dev

🔇 Additional comments (2)

hypersync-net-types/Cargo.toml (2)

3-3: ✓ Semver issue from previous review has been addressed.

The version bump from 0.10.0 to 0.11.0-rc.1 correctly implements a minor version bump for the breaking changes (generic Selection<T> types and converted concrete types to aliases). This addresses the critical semver concern raised in the prior review.

Note: Verify that the hypersync-client crate's dependency reference has also been updated to "0.11" to reflect this breaking change.

---

18-20: ✓ Dev-dependencies additions support backward-compatibility tests.

The addition of serde_json and pretty_assertions as dev-dependencies is appropriate and aligns with the PR's backward-compatibility test additions (deserialization and round-trip serialization tests mentioned in the summary).

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 3

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a1ec5d3 and 5ad7595.

📒 Files selected for processing (5)

• .github/workflows/ci.yaml (1 hunks)
• hypersync-client/src/preset_query.rs (4 hunks)
• hypersync-client/tests/api_test.rs (2 hunks)
• hypersync-net-types/Cargo.toml (1 hunks)
• hypersync-net-types/src/lib.rs (5 hunks)

🧰 Additional context used

🧬 Code graph analysis (2)

hypersync-client/tests/api_test.rs (1)

hypersync-net-types/src/lib.rs (1)

• from (27-32)

hypersync-client/src/preset_query.rs (1)

hypersync-net-types/src/lib.rs (1)

• from (27-32)

🪛 actionlint (1.7.7)

.github/workflows/ci.yaml

22-22: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

---

23-23: the runner of "actions-rs/toolchain@v1" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

---

45-45: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

---

46-46: the runner of "actions-rs/toolchain@v1" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

---

68-68: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

---

69-69: the runner of "actions-rs/toolchain@v1" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

🔇 Additional comments (14)

.github/workflows/ci.yaml (2)

72-72: Good addition of explicit component dependencies.

Explicitly declaring rustfmt and clippy as required components ensures the lint job has the necessary tools. This is a best practice for CI reliability.

---

22-40: LGTM: Consistent formatting improvements.

The indentation and structure changes improve readability and maintain consistency across all three jobs. The workflow logic remains unchanged aside from the beneficial addition of explicit components in the lint job.

Also applies to: 45-63, 68-87

hypersync-client/src/preset_query.rs (4)

6-8: LGTM! Import updates align with the new API.

The imports correctly bring in the new LogFilter and TransactionFilter types required for the refactored selection constructors.

---

86-89: LGTM! Correct usage of the new From-based construction.

The LogSelection::from(LogFilter { ... }) pattern correctly leverages the new generic Selection<T> API, preserving the original filter semantics while adopting the new type structure.

---

121-125: LGTM! Consistent with the new filter construction pattern.

The construction correctly uses LogSelection::from(LogFilter { ... }) with topics and address fields, maintaining the original query semantics.

---

175-178: LGTM! Transaction filter construction follows the established pattern.

The TransactionSelection::from(TransactionFilter { ... }) correctly constructs the selection with the from field, consistent with the refactored API.

hypersync-client/tests/api_test.rs (2)

8-8: LGTM! Import correctly updated for the new API.

The addition of TransactionFilter to the imports enables the test to use the new filter construction pattern.

---

461-464: LGTM! Test correctly updated to use the new From-based construction.

The test properly constructs TransactionSelection via TransactionSelection::from(TransactionFilter { ... }), using the from_filter field with a bloom filter. This maintains the original test semantics while adopting the refactored API.

hypersync-net-types/src/lib.rs (6)

26-33: LGTM! From implementation provides ergonomic construction.

The From<T> implementation allows users to construct Selection<T> from just a filter, defaulting exclude to None. This maintains backward compatibility for users who don't need negative filtering while enabling the new feature.

---

35-47: LGTM! BlockFilter correctly encapsulates block filtering logic.

The BlockSelection type alias and BlockFilter struct cleanly separate the selection wrapper from the filter criteria. The hash and miner fields are well-documented with their empty-vector semantics.

---

49-63: LGTM! LogFilter properly encapsulates log filtering criteria.

The LogSelection alias and LogFilter struct correctly expose address, address_filter (bloom), and topics fields with clear documentation.

---

65-108: LGTM! TransactionFilter comprehensively covers transaction filtering.

The TransactionSelection alias and TransactionFilter struct provide extensive filtering capabilities including from/to addresses (with bloom filter support), sighash, status, type, contract address, hash, and authorization list. Field documentation is clear about AND/OR relationships.

---

120-145: LGTM! TraceFilter follows consistent design pattern.

The TraceSelection alias and TraceFilter struct maintain consistency with other filter types, providing from/to/address filtering (with bloom support), call_type, reward_type, kind, and sighash fields.

---

209-216: LGTM! Documentation added to JoinMode variants.

The added documentation clarifies the behavior of each JoinMode variant, improving API usability.

[JasoonS]

Check the '/examples'

[JonoPrest]

Check the '/examples'

Checked, they all build and they were part of the workspace to begin with 👍🏼