Repository navigation
Count custom-food ingredients in a recipe's batch; verify every recipe save - #11
Merged
Merged
Conversation
…e save Cronometer adds an ingredient's grams to a recipe's "full recipe" weight only when all of the ingredient food's measures are type "Weight". create_custom_food saved its serving as "Atomic", so a recipe using one of those foods got a 0 g (or short) batch and inflated per-100 g nutrients, while create_recipe still reported success. - create_custom_food saves the serving as "Weight", as the web client does for a serving with a gram weight. The server then adds its own "g" measure, so the serving is found as the measure that isn't that g. - update_custom_food re-types weighed "Atomic" measures as "Weight" on every save, so older foods are fixed by any edit (diary math is unchanged). - create_recipe / update_recipe refuse ingredients with a non-"Weight" measure before saving, and after saving check the stored batch weight and the energy/protein/fat/carbs against the ingredients, raising on a mismatch. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…e-type shim A Weight serving gets a server-added g, so update_custom_food's per-serving edits on new foods needed measure_id. _custom_food_serving now ignores g/oz when exactly one other measure remains, replacing _created_serving. Older custom foods with Atomic servings are refused as recipe ingredients rather than silently re-typed on any edit; they get a one-time migration. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a recipe used one of our custom foods as an ingredient, it was stored with the wrong batch weight, and
create_recipestill reported success.Root cause (verified live): Cronometer adds every ingredient's nutrients to a recipe, but adds its grams to "full recipe" only when all of the food's measures are
Weight.create_custom_foodsaved servings asAtomic. In one test, 80 g of a 400 kcal/100 g food gave a 0 g batch at 320 kcal/100 g. The web client saves a weighed serving asWeight;Atomicis for count units.Changes
create_custom_foodsaves the serving asWeight. The server adds agmeasure, which_custom_food_servingignores.create_recipe/update_reciperefuse non-Weightingredients before saving. After saving, they check the batch weight and macros, and raise on a mismatch.The only legacy
Atomiccustom food is the milk, 85083211. Colin's six recipes and 160 database foods were allWeight.Live: I tested these on ZZ foods (now retired): new food → update → recipe, the refusal, and a broken batch being caught. 830 tests pass; ruff is clean.
🤖 Generated with Claude Code