fix(web): label section recipes from their saved config

[Tobechukwu-Njoku]

Fixes #586.

What happened

recipeLabel resolves a section's badge by finding its recipe definition and returning found.presets[0].display_name — the first registered preset — without ever looking at the config the section was saved with (web/src/components/sections/EditableSectionRows.tsx:25 before this change).

The presets of one recipe differ only by their default_params, so the first preset is not a stand-in for the rest. trending_discover registers three (internal/sections/recipes/trending_discover.go:52-54):

preset	default_params	display name
tdisc_tmdb_day	{"source":"tmdb","window":"day"}	TMDB Trending Today
tdisc_tmdb_week	{"source":"tmdb","window":"week"}	TMDB Trending This Week
tdisc_trakt	{"source":"trakt","window":"week"}	Trakt Trending

All three rendered as "TMDB Trending Today". That confirms the suspicion in the issue that Trakt Trending is mislabeled the same way — it is, and there's now a test for it.

This is not trending-specific

Worth flagging, since the issue reads as a single-section problem. Enumerating the registry, 10 of the 33 registered recipe types ship more than one preset:

mood_collection        8 presets
collection             7
editorial_spotlight    4
format_showcase        4
trending_on_server     3
award_winners          3
trending_discover      3
most_watched           2
continue_watching      2
seasonal_themed        2

That's 38 presets across those types, of which the 28 non-first ones all render the wrong label. trending_discover is just where it was noticed. Fixing recipeLabel rather than special-casing trending covers all of them in one change, which is why the diff is a bit larger than the report implies.

Approach

Sections don't record which preset created them — sections carries section_type and a config jsonb and nothing else (migrations/sql/001_schema.sql:613), and there's no preset-key column anywhere. So the preset has to be recovered by matching its default_params against that config.

presetMatchScore requires every one of a preset's default_params to agree with the config and scores by how many matched, so the most specific preset wins. Requiring all of them is what separates tmdb/week from trakt/week — matching on the distinguishing key alone would not. Extra config keys the section carries (media_scope, item_limit, …) are ignored.

It falls back to presets[0] whenever nothing matches, so sections saved before a preset existed, or with hand-edited config, keep exactly the label they have today.

Both render sites already had the section in scope, so they just pass section.config.

I left SectionEditorDrawer.tsx:398 alone: it uses presets[0] to name a section type in a picker where no section config exists yet, which is a different question from labeling a saved section.

Tests

New web/src/components/sections/EditableSectionRows.test.ts, 8 cases against the real trending_discover preset shape: each variant labeled from its config, Trakt-vs-TMDB on the same window, extra config keys ignored, and four fallback paths (no config, unmatched config, unknown type, no catalog).

Three fail before the change and pass after:

× labels the weekly TMDB preset from its saved config
    expected 'TMDB Trending Today' to be 'TMDB Trending This Week'
× distinguishes Trakt from TMDB on the same window
    expected 'TMDB Trending Today' to be 'Trakt Trending'
× ignores unrelated config keys the section also carries
    expected 'TMDB Trending Today' to be 'Trakt Trending'

The five fallback cases pass both before and after — they pin the behavior this change is meant not to alter.

Gate

• pnpm exec tsc --noEmit — clean
• pnpm exec eslint on both changed files — 0 errors. The one react-refresh/only-export-components warning on EditableSectionRows.tsx is pre-existing (recipeLabel was already an exported non-component); verified identical on a clean baseline, it just moved from line 25 to 79.
• make test-web — compared against a clean main working tree:

	clean main	this branch
test files failed	4	4
tests failed	36	36
test files total	283	284
tests passed	1987	1995

Identical failure counts; the delta is exactly this PR's one new file and its 8 passing tests. The 36 pre-existing failures are in storage.test.ts, useTheme.test.ts, appearanceCacheOwnership.test.tsx and settingValuesRealtime.test.tsx — untouched by this change, and I did not add anything to WEBTEST_KNOWN_FAILURES.

No Go files touched.

Note

Written with AI assistance (Claude), per CONTRIBUTING. I've read the change, run the gate above, and can explain the reasoning and alternatives.

Summary by CodeRabbit

• New Features

  • Section labels now reflect the specific preset and settings used by a saved recipe.
  • Labels distinguish presets with different default parameters, while ignoring unrelated configuration details.
  • Section badges and drag-and-drop overlays now display consistent, configuration-aware labels.
  • Added clear fallback labels for missing, unmatched, generic, or unavailable catalog configurations.

• Tests

  • Added comprehensive coverage for preset matching, differentiation, and fallback behavior.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 5be165d8-2459-4c65-9f71-e63fe1b4e378

📥 Commits

Reviewing files that changed from the base of the PR and between 91c3d7b and 02b702a.

📒 Files selected for processing (2)

• web/src/components/sections/EditableSectionRows.test.ts
• web/src/components/sections/EditableSectionRows.tsx

Included review availability: Your plan provides up to 2 included reviews per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

The web UI now matches shared recipe types to presets using saved section configuration. Section badges and drag overlays use the resolved preset label. Tests cover parameter matching, fallback behavior, unrelated keys, missing catalog entries, and raw type labels.

Changes

Recipe label resolution

Layer / File(s)	Summary
Preset matching and label integration web/src/components/sections/EditableSectionRows.tsx, web/src/components/sections/EditableSectionRows.test.ts	recipeLabel accepts optional configuration, compares it with preset default_params, selects the best matching preset, and falls back when needed. Section badges and drag overlays pass section configuration. Tests cover matching and fallback cases.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Merge Risk: ⚪ Minimal · up to 02b70

This localized labeling change is merge-ready after normal checks and review; no actionable merge-blocking risk remains.

Suggested reviewers: quick104

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 6 functions across 2 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: labeling section recipes from saved configuration.
Linked Issues check	✅ Passed	The changes address issue #586 by matching saved configuration to preset defaults and labeling TMDB and Trakt variants correctly.
Out of Scope Changes check	✅ Passed	The implementation and tests remain within the scope of configuration-based recipe labeling described in issue #586.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Tobechukwu-Njoku]

Flagging a mechanical blocker rather than asking for priority. The CI workflow on this PR is sitting at action_required and hasn't run. As a first-time-contributor it needs someone with write access to approve the run once. Nothing I can do from this side.

Re-checked against main just now, in case it had drifted:

• Still merges cleanly; nothing upstream has touched web/src/components/sections/EditableSectionRows.tsx.
• pnpm exec vitest run src/components/sections/EditableSectionRows.test.ts — 8/8 passing.

The full gate results, and the comparison showing the pre-existing make test-web failures are unrelated to this change, are in the PR description. Happy to rebase or split it differently if that's easier to review.