fix(rundown): narrow rundown invalidation

Two independent issues in the revision strategy.

The client guard only skipped a refetch when the revision matched exactly,
while its comment described skipping anything not newer. A message which
arrives after a refetch has already brought in a later revision forced a
needless refetch. Compare with <= so the guard does what it claims.

Renaming a rundown re-initialised it, which stops playback. Renaming the
loaded rundown during a show therefore stopped the show. A title has no
bearing on the schedule, so it now goes through an ordinary transaction:
the title is persisted, the revision bumped and clients notified, with no
runtime involvement. Renaming to the current title is a no-op.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011a5cbVjNC5XXF88b2PkUCa
This commit is contained in:
Claude
2026-08-30 10:51:20 +00:00
parent 1fa6175fb8
commit a5086aed0b
2 changed files with 17 additions and 21 deletions
+3 -3
View File
@@ -242,12 +242,12 @@ export function maybeInvalidateRundownCache(revision: MaybeNumber, rundownId?: s
return;
}
// skip if we dont recognise the ID the revision is lower
const queryKey = getRundownQueryKey(rundownId);
const cachedRundown = ontimeQueryClient.getQueryData<{ revision: number }>(queryKey);
if (revision === cachedRundown?.revision) {
// we already have the latest change
// we already have this change, or something newer
// messages can arrive after a refetch has already brought in a later revision
if (revision !== null && cachedRundown !== undefined && revision <= cachedRundown.revision) {
return;
}