Org Web Adapter

Editing hungryroot/jira/be_7006_add_ingredient_productid_filter_to_v3_pairing_and_v3_filter_pairing.org

:PROPERTIES:
:ID:       1a10b7d7-3174-43b6-8ef0-c6e570c17173
:END:
#+title: BE-7006 Add Ingredient (productId) filter to V3 Pairing and V3 Filter Pairing

- source :: https://hungryroot.atlassian.net/browse/BE-7006
- tags   :: [[id:3a477c02-e26d-40f7-a719-0aa1cd169dd8][Hungryroot API Project]]  [[id:5179afe7-2259-473c-abde-a1682c1a8e0c][Hungryroot Customize POD]]
- epic   :: [[id:6b92ba3f-7467-4e9c-b2b8-9a453aaa04f9][EP-528 (Customize) Recipes from ingredients]]
- sprint :: [[id:c82bb209-ab05-47b1-8f5d-3eebfb7a808a][HR BE Sprint 103]]
- status :: [[id:4d41d978-e56f-45c1-88d1-e2c76510972e][Status - Complete]]

* Tasks
** DONE Review V3 API to see where filtering should go for product_ids :work:api:v3:hungryroot:sprint103:ep528:be7006:
:PROPERTIES:
:ID:       45c379ac-07e3-054d-fb72-ad3f0cd17118
:END:

- Note taken on [2026-02-03 Tue 12:31]

Turns out this was already done with the V2 ticket  [[id:88d775d4-5bfb-4e12-8421-700bc15b9972][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