Problem
When a .cook file changes upstream, GitHubIndexer::index_recipe (src/github/indexer.rs) updates only the file SHA. The recipes.content column is never refreshed, so the stored recipe body silently drifts from what's actually in the repository.
The update arm still carries a comment admitting it:
// Update recipe content (use existing update function if available)
// For now, we'll keep the existing recipe and just update the github_recipe SHA
db::github::update_github_recipe_sha(&self.pool, existing.id, file_sha).await?;
Why it matters more than it looks
The code after that branch re-extracts ingredients, cookware, tags — and now locale (added in #11) — from the newly downloaded content. So a changed recipe ends up with:
- derived data (ingredients / tags / locale) computed from the new file, and
recipes.content still holding the old file.
The row asserts a locale and an ingredient list describing text the database doesn't store. The recipe detail page renders from recipes.content, so users see the stale body alongside fresh derived metadata.
Note the early return upstream means this only fires when the SHA genuinely changed — i.e. exactly when the content did change:
if existing.file_sha == file_sha {
return Ok(existing.recipe_id); // unchanged file, nothing to do
}
Suggested fix
On the update path, refresh the recipe row from the new content — title, summary, image, content, and content_hash — the way the feed crawler already does via db::recipes::update_recipe_with_content (which recomputes locale as part of the same call).
Context
Found while implementing recipe locale detection (#11). Deliberately left out of scope there: it's a pre-existing bug and bigger than locale.
Problem
When a
.cookfile changes upstream,GitHubIndexer::index_recipe(src/github/indexer.rs) updates only the file SHA. Therecipes.contentcolumn is never refreshed, so the stored recipe body silently drifts from what's actually in the repository.The update arm still carries a comment admitting it:
Why it matters more than it looks
The code after that branch re-extracts ingredients, cookware, tags — and now locale (added in #11) — from the newly downloaded content. So a changed recipe ends up with:
recipes.contentstill holding the old file.The row asserts a locale and an ingredient list describing text the database doesn't store. The recipe detail page renders from
recipes.content, so users see the stale body alongside fresh derived metadata.Note the early return upstream means this only fires when the SHA genuinely changed — i.e. exactly when the content did change:
Suggested fix
On the update path, refresh the recipe row from the new content — title, summary, image,
content, andcontent_hash— the way the feed crawler already does viadb::recipes::update_recipe_with_content(which recomputes locale as part of the same call).Context
Found while implementing recipe locale detection (#11). Deliberately left out of scope there: it's a pre-existing bug and bigger than locale.