fix(foodEntryService): forward meal_type_id to repository in createFoodEntryMeal

[marcelosj3]

Summary

createFoodEntryMeal in foodEntryService.js receives meal_type_id in mealData (correctly passed from the route), but drops it when constructing the object sent to foodEntryMealRepository.createFoodEntryMeal().

This forces the repository to always use the string-based fallback lookup:

SELECT id FROM meal_types WHERE LOWER(name) = LOWER($1)

…which causes 500 errors when the meal type name doesn't match exactly (e.g. casing differences, custom meal type names).

Root Cause

foodEntryMealRoutes.js correctly destructures and forwards meal_type_id:

// route — correct ✅
const { meal_type, meal_type_id, ... } = req.body;
await foodEntryService.createFoodEntryMeal(targetUserId, userId, {
  meal_type,
  meal_type_id,   // <-- passed in
  ...
});

foodEntryService.js receives it in mealData but drops it before calling the repository:

// service — bug ❌
await foodEntryMealRepository.createFoodEntryMeal({
  meal_type: mealData.meal_type,
  // meal_type_id is never forwarded
}, actingUserId);

foodEntryMealRepository.js already handles meal_type_id correctly — it just never receives it:

// repository — already correct ✅
let mealTypeId = foodEntryMealData.meal_type_id;
if (!mealTypeId && foodEntryMealData.meal_type) {
  // string-based fallback
}

Fix

Add meal_type_id: mealData.meal_type_id || null to the object passed to the repository:

await foodEntryMealRepository.createFoodEntryMeal({
  user_id: mealData.user_id || authenticatedUserId,
  meal_template_id: mealData.meal_template_id || null,
  meal_type_id: mealData.meal_type_id || null,   // <-- added
  meal_type: mealData.meal_type,
  ...
}, actingUserId);

When meal_type_id is provided, the repository uses the direct UUID path. When it's absent, the existing string-based fallback still works as before — no behaviour change for existing callers.

Testing

• Create a food entry meal with a valid meal_type_id UUID → should resolve correctly without string lookup
• Create a food entry meal with only meal_type string → existing fallback still works
• Create with neither → existing error handling unchanged

[gemini-code-assist]

Summary of Changes

Hello @marcelosj3, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical bug in the foodEntryService that prevented the meal_type_id from being correctly passed to the repository layer. The fix ensures that meal type lookups can leverage direct ID-based resolution, thereby eliminating 500 errors that occurred when the string-based fallback failed due to inconsistencies in meal type names. This enhancement significantly improves the robustness and reliability of the food entry creation process.

Highlights

• Bug Fix: meal_type_id Dropped: Resolved an issue where meal_type_id was not being forwarded from foodEntryService to the foodEntryMealRepository, leading to incorrect meal type lookups.
• Improved Meal Type Resolution: Ensured that meal_type_id is now correctly passed, allowing the repository to use direct UUID lookups and preventing 500 errors caused by string-based fallbacks.
• Enhanced Robustness: The change improves the reliability of creating food entries by prioritizing direct ID-based lookups over potentially error-prone string matching.

Changelog

• SparkyFitnessServer/services/foodEntryService.js
  • Forwarded meal_type_id to the foodEntryMealRepository when creating a food entry meal.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly forwards the meal_type_id from the service layer to the repository in createFoodEntryMeal. This is a good fix that avoids a potentially failing database lookup by meal type name when the ID is already available. The implementation is clean and correct.

While reviewing, I noticed that foodEntryMealRoutes.js also handles meal_type_id for the update operation. It might be worth verifying if foodEntryService.updateFoodEntryMeal correctly forwards this ID to the repository as well, to prevent a similar issue in the update logic.