feat: add batch order hash trade lookup#2572
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml 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 |
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
How to use the Graphite Merge QueueAdd the label Raindex-queue to this PR to add it to the merge queue. You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
## Chained PRs - Stacked on [#106](#106) for the taker trades endpoint. - Also follows [#105](#105) for the token trades endpoint. ## Dependent PRs - Depends on [rainlanguage/raindex#2572](rainlanguage/raindex#2572) ([Graphite](https://app.graphite.com/github/pr/rainlanguage/raindex/2572)) for SDK `getTradesByOrderHashes` support, local DB order-hash batching, and grouped results. This PR should not merge until that raindex PR lands and the submodule pointer is mergeable. ## Summary - Adds `POST /v1/trades/query` for batch order-hash trade lookup. - Defines request/response DTOs for `orderHashes` input and `tradesByOrderHash` grouped output. - Includes every requested hash in the response through the SDK grouping behavior, including hashes with no trades. - Validates order hashes with existing API error handling and returns `400` for invalid hash input. - Wires the route through the existing trades module, auth, rate limiting, tracing span propagation, and OpenAPI registration. - Uses the raindex SDK batch order-hash API directly; there is no API-side query workaround. - Reuses the shared trade list mapper for each grouped trade entry. - Bumps the `rain.orderbook` submodule to the SDK commit with batch order-hash trade lookup support. Linear: RAI-528 ## Behavior The new endpoint accepts a JSON body: ```json { "orderHashes": [ "0x4a051ad4567935a5a0570b3e2e77714c44405bb58e5b83e3cc484de1cee0747e" ], "startTime": 1718452800, "endTime": 1718539200 } ``` It returns trades grouped by requested order hash: ```json { "tradesByOrderHash": [ { "orderHash": "0x4a051ad4567935a5a0570b3e2e77714c44405bb58e5b83e3cc484de1cee0747e", "trades": [] } ], "totalCount": 0 } ``` ## Local DB Smoke Test After clearing the local raindex DB and waiting for the Base local source to become ready, the endpoint used local DB only: ```text local_chain_ids_count=1 subgraph_chain_ids_count=0 ``` Single-order smoke test: - Request: one real order hash plus one zero hash. - Result: real hash returned `50` trades; zero hash returned an empty `trades` array. - HTTP total: `0.415652s`. - SDK local fetch: `29ms`; SDK total: `161ms`. Heavy response stress test using the highest-trade order hashes in the local DB: - Top 10 order hashes: `3,790` trades, `2.12 MB` response, HTTP total `11.20s`. - Top 20 order hashes: `4,596` trades, `2.57 MB` response, HTTP total `13.50s`. - Top 20 SQL fetch was `930ms`; full SDK grouping/materialization was `13211ms`; full API request was `13495ms`. The heavy case is dominated by materializing, grouping, mapping, and serializing thousands of full trade objects rather than by SQL lookup. ## Notes - The `unimplemented!()` additions are test-only mock methods required by the expanded `TradesDataSource` trait; they are not production route code. - Empty `orderHashes` currently returns an empty grouped result, matching the SDK behavior. ## Verification - `nix develop -c cargo fmt` - `nix develop -c cargo check` - `nix develop -c cargo test routes::trades::get_by_order_hashes` - `nix develop -c cargo test` - `nix develop -c rainix-rs-static` `rainix-rs-static` passes with pre-existing dead-code warnings in `src/cache.rs`.
2 participants
Related Issue
Dependent PRs
Motivation
Consumers need to fetch trades for multiple order hashes without issuing one SDK query per hash. Running many independent trade lookups would duplicate local DB reconstruction work and subgraph pagination work, especially when callers need results for dozens of orders.
Solution
RaindexClient.getTradesByOrderHashes, exposed to wasm asgetTradesByOrderHashes, returning trades grouped by requested order hash.FetchTradesArgswithorder_hashesand push the batch predicates into the trade source CTEs, includingmatching_clears,take_trades,clear_alice, andclear_bob.orderHash_insupport and issue onetrades_list_allrequest for all requested hashes.Checks
By submitting this for review, I confirm I have done the following:
Additional validation run:
cargo fmt --allnix develop -c cargo test -p rain_orderbook_common fetch_tradesnix develop -c cargo test -p rain_orderbook_common get_by_order_hashesnix develop -c cargo test -p rain_orderbook_commonnix develop -c cargo test -p rain_orderbook_subgraph_clientnix develop -c rainix-wasm-testnix develop -c rainix-rs-static