Fields 'product_quantity' and 'product_quantity_unit' not returned

[SkypLabs]

What

• The fields product_quantity and product_quantity_unit are not returned when also requesting some nutrition facts.

Steps to reproduce the behaviour

1. Click on https://fr.openfoodfacts.org/api/v2/product/3254560034709?fields=product_name,brands,product_quantity,product_quantity_unit,nutrition_grade_fr,nova_group,energy-kcal_100g
2. The product_quantity and product_quantity_unit fields are absent even though they were requested.
3. Now click on https://fr.openfoodfacts.org/api/v2/product/3254560034709?fields=product_name,brands,product_quantity,product_quantity_unit,nutrition_grade_fr,nova_group
4. The product_quantity and product_quantity_unit fields are present this time.

Expected behaviour

• The product_quantity and product_quantity_unit fields should be present in both cases.

Why

• It seems that the product_quantity and product_quantity_unit fields are not returned when requesting at the same time nutrition facts.

[harsh-791]

The root cause is in the v2 compatibility path: when you request an old-style nutriment like energy-kcal_100g, the schema downgrade calls normalize_product_quantity_and_serving_size, which deletes product_quantity(_unit) and can’t recompute them because quantity isn’t present in the partial product.
So product_quantity and product_quantity_unit disappear only when a _100g nutriment is requested alongside them.
My proposed fix is to temporarily include quantity in customize_response_for_product’s “needed fields” list, just like schema_version and serving_size, before calling api_compatibility_for_product_response.
Concretely: in ProductOpener::API::customize_response_for_product, add "quantity" to the @needed_field list so the converter can recompute product_quantity and product_quantity_unit correctly while still stripping quantity from the final response.

[stephanegigandet]

@harsh-791 Yes, that should work.

[harsh-791]

Thanks for confirming!
I have opened a PR for the same : #13143

[harsh-791]

@stephanegigandet can you please review my pr