[Bug]: Event Sync pre-flight message for a curated master group reads as a lookup failure, but the check is an ownership constraint

[lukeeexd]

ECM Version

0.18.1 (source references below verified against main at 0.18.2-0036)

Priority

Priority 4: When you get to it

What is the bug?

Previewing an Event Sync rule whose master group is a hand-curated Dispatcharr channel group (one that does not come from any M3U account) fails pre-flight with:

Master group 1644 was not found in the M3U account's group settings — the group may have been removed or renamed, or that provider does not carry it.

The message describes a lookup failure (a group that went missing), but the group exists and has 16 channels. What the check is really enforcing is a design constraint: the master group must be M3U-backed because Dispatcharr owns master channel lifecycle (docs/event_sync.md:67). Nothing in the message says that, so an operator reads it as a stale-config error and goes looking for a group that was never supposed to be in the M3U junction table.

What is and is not blocked by this failure (traced in source):

• The check is group_settings_found in check_event_sync_group_settings, backend/services/event_sync_preflight.py:257. It fires when the group id has no row in any M3U account's channel_groups junction and is not a Channel Group Override target.
• Preview is not blocked. backend/routers/channel_pipeline.py:3906 records the failure and then fetches the master channels and resolves matches anyway. The UI renders the failure as a warning banner above full results.
• Manual Run and Test are not blocked. The engine only pre-flights unattended triggers, backend/channel_pipeline_engine.py:4406. The attach path filters channels by channel_group_id and never reads auto_created or the junction row.
• Unattended auto-run is blocked. The same engine path fails closed and skips the rule with a persisted warning.
• Stale-stream cleanup is blocked. plan_cleanup in backend/services/event_sync_cleanup.py:150 returns configured_group_settings_unavailable on any group_settings_found failure, so detach_stale_streams never runs for such a master.

So the check is defensive rather than structural: the resolve/attach mechanism only needs channels in the master group whose names (or first attached stream names) parse to title plus start time. The auto_channel_sync ON requirement encodes the ownership model, not a code dependency.

Steps to Reproduce

1. Create a Dispatcharr channel group by hand and populate it with event channels whose names carry a start time (here: group 1644, Events | Snooker, 16 channels).
2. Create an Event Sync rule with that group as master and M3U-backed secondaries (here: 1283 and 1531, two providers' copies of the same MAX UK grid). The rule editor's picker will not offer a junction-less group, so use the API or an inline preview config.
3. Call preview_event_sync.
4. Pre-flight reports FAILED with the message above. The preview beneath it still resolves and reports matches.

Screenshots / Logs / Artifacts

Live preview against master 1644, secondaries 1283 + 1531:

pre-flight: FAILED
  Master group 1644 was not found in the M3U account's group settings — the group may have been removed or renamed, or that provider does not carry it.

200 secondary streams -> 32 would attach, 0 ambiguous, 6 unmatched, 162 parse failed | 16 master channels (0 unparsable)

Individual would_attach rows scored score=1.0, dt=0.0m. A run labelled FAILED producing 32 perfect matches is the clearest sign the wording does not describe what the check means. (The 162 parse failures are secondary stream names with no time in them, unrelated to this issue.)

Additional Context

Dispatcharr 0.30.0.

Minimal fix (I will open a PR for this): reword the group_settings_found message for the master role to say that the master group must be M3U-backed because Dispatcharr owns master channel lifecycle, and that a curated group is not supported as a master; add a matching note to docs/event_sync.md. No behaviour change.

Possible relaxation (your call, not presumed): for a whole-group master scope (m3u_account_id null) with no junction row on any account, downgrade group_settings_found from a failure to a warning stating that the group is treated as operator-curated and ECM will not auto-create channels in it. Keep the failure for provider-scoped master scopes and for all secondaries, since those are genuine stale configs. Follow-on pieces would be: the cleanup gate accepts the warning, the unattended path stops skipping the rule, a curated-master test, a docs note, and the rule editor's picker listing junction-less channel groups so the case is reachable without the API. Snapshot/rollback already treats curated channels as ordinary ECM-side channels (full-payload restore), which looks right for operator-owned channels.

This touches the ownership model the docs set out, so I am not assuming it is wanted. Happy to implement it in a separate PR if you would like it.