Org Web Adapter

hungryroot/jira/be_6936_add_ingredient_productid_filter_to_pairinglist_api_with_perf_eval.org

ID
88d775d4-5bfb-4e12-8421-700bc15b9972

BE-6936 Add ingredient - productId - filter to PairingList API with perf eval

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

- tags :: Hungryroot API Project

- epic :: [[id:6b92ba3f-7467-4e9c-b2b8-9a453aaa04f9][EP-528 [Customize] Recipes from ingredients]]

- sprint :: HR BE Sprint 102

- status :: Status - Complete

- pull :: https://github.com/hungryroot/hungryroot/pull/13011

Tasks

DONE Get Cursor to weigh in on adding

pairingsworkfeatureep528be6936filteringhungryrootapicursor
ID
72d0f0da-47ce-88a6-d2f5-030bfc570e6d

DONE Open a pull request with the new filter

workfeatureep528be6936filteringhungryrootapicursorpairings
ID
78a7219a-8f60-ac8e-6c4f-0312d96e1ff0

DONE Fix query tests and screenshots on PR

pairingsworkfeatureep528be6936filteringhungryrootapi
ID
554cf2f2-1de7-6e42-6b01-a7e89197fbb6

DONE Fix query tests again

projectep528be6936Jpairingswork
ID
a16b030f-d1ef-70de-8985-da3a7379928e

DONE Test that product_ids filter works in QA

projectep528be6936apiworkhungryrootqa
ID
1eaf2a08-2f9a-7c4e-2f8a-93a00d04eaa7

Description

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

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

this

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