feat: add taker filters to getTrades#2571
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. |
c621884 to
7d24eb3
Compare

Related Issue
Dependent PRs
Motivation
Consumers need the SDK-level
getTradesAPI to support filtering by taker address. The REST API work identifies the taker address as the trade event sender, which is available in the raindex local DB and subgraph trade models.For the local DB path, the taker predicate also needs to be applied before the trade reconstruction CTEs expand and hydrate rows. Filtering only after the normalized trade result forces SQLite to build a much larger intermediate result set before returning the requested page.
Solution
takersto the existingGetTradesFiltersSDK filter shape.FetchTradesArgsand push the SQL predicate into the source CTEs:take_orders.sender IN (...)andclear_v3_events.sender IN (...).take_ordersandclear_v3_eventsto support the new taker lookup path.getTradesfetch/count tracing with filter counts, parameter count, row/count results, and duration.TradeEvent_filterbinding and map takers totradeEvent_: { sender_in: [...] }.getTradespagination, time, owner, order hash, orderbook, and token filter behavior.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 -p rain_orderbook_subgraph_clientnix develop -c cargo test --workspace