Org Web Adapter

hungryroot/jira/be_7006_add_ingredient_productid_filter_to_v3_pairing_and_v3_filter_pairing.org

ID
1a10b7d7-3174-43b6-8ef0-c6e570c17173

BE-7006 Add Ingredient (productId) filter to V3 Pairing and V3 Filter Pairing

- source :: https://hungryroot.atlassian.net/browse/BE-7006

- tags :: Hungryroot API Project Hungryroot Customize POD

- epic :: EP-528 (Customize) Recipes from ingredients

- sprint :: HR BE Sprint 103

- status :: Status - Complete

Tasks

DONE Review V3 API to see where filtering should go for product_ids

workapiv3hungryrootsprint103ep528be7006
ID
45c379ac-07e3-054d-fb72-ad3f0cd17118

- Note taken on

Turns out this was already done with the V2 ticket BE-6936 Add ingredient - productId - filter to PairingList API with perf eval

Description

https://hungryroot.slack.com/archives/C02N30ZNRSQ/p1767716553710809

https://hungryroot.slack.com/archives/C08PVEQ3QUT/p1761750662131689

Parfait did this ^

This ticket is a clone of the v2 ticket meant to track the same change for the

v3 endpoints

We want to add support for filtering recipes (Pairings) by ingredient

(productId) in the PairingList API endpoint.

This work involves extending both:

PairingList(SideloadableRelationsMixin, ListAPIView) in Django REST Framework,

and

PairingFilter(DietaryFiltersMixin, DietaryRestrictionFiltersMixin,

SaleFilterMixin, FilterSet)

to allow clients to filter pairings/recipes by one or more ingredient product

IDs.

In addition to implementing the filter, this ticket should explicitly evaluate

and ensure acceptable performance characteristics. Filtering by ingredient has

the potential to introduce expensive joins or large result sets, so we need to

confirm whether this is safely supported by existing schema and indexes, or

whether additional indexing, query refactors, or constraints are required.

If this type of filtering is not currently safe to support at scale, the

investigation should document:

Whether existing DB indexes would reasonably support this in the future

Whether additional DB or UI-level constraints would be required

Any performance risks or follow-up investigation needed before enabling this

broadly

Acceptance Criteria

Add a filter option to PairingFilter that allows filtering recipes by ingredient

productId

Wire the filter into PairingList so the API supports the new query parameter

Validate query behavior with realistic data sizes (joins, cardinality, and

execution plans)

Confirm that performance is acceptable for production usage (or clearly document

why it is not)

If performance is questionable:

Identify missing or required DB indexes

Document potential schema or UI constraints needed to make this safe

Provide a recommendation on whether this should ship as-is, behind a flag, or

require follow-up work

Add basic tests or query validation to ensure correctness and guard against

regressions

Notes / Considerations

Pay close attention to join paths between Pairings, recipes, and ingredients

Consider whether multi-value ingredient filters are in scope or should be

explicitly constrained

Be explicit about any tradeoffs or assumptions so Product/UI can make informed

decisions