fix: prevent undesired timelines reaching TSR

[ianshade]

About the Contributor

This pull request is posted on behalf of TV 2 Norge.

Type of Contribution

This is a:

Bug fix

Current Behavior

Timeline might be saved and fast-tracked to TSR (Playout Gateway) before it is certain that the result of the playout job will be committed.
Moreover, it happens before onRundownActivate/onRundownDeactivate callbacks run. Consequence is twofold:

• when an exceptions is thrown during one of those callbacks, an unwanted timeline is still sent to the TSR as if activation/deactivation succeeded
• those callbacks, even though capable, thanks to their contexts, can't be used to perform TSR actions (e.g. initializations and cleanups) that need to execute before the timeline changes from/to the studio baseline, which is crucial to avoid intermittent states (when the rundown timeline briefly reaches a device that has not been fully initialized)

New Behavior

This pull request refactors and improves how and when timeline updates are triggered, generated, and published for both playlists and studios in the playout worker. The key change is to decouple timeline generation from immediate execution, instead marking that a timeline update is needed and regenerating timelines just before saving the model - when it is definitely correct and safe to do so. The operations are ordered so that lenghty execution of the callbacks does not contribute to the latency measured between timeline generation and its resolution in TSR.

Testing

• I have added one or more unit tests for this PR
• I have updated the relevant unit tests
• No unit test changes are needed for this PR

Affected areas

Playout logic - generating, fast-tracking and saving the timeline

Time Frame

Other Information

Status

• PR is ready to be reviewed.
• The functionality has been tested by the author. (before porting to release53)
• Relevant unit tests has been added / updated.
• Relevant documentation (code comments, system documentation) has been added / updated.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

• 🔍 Trigger a full review

---

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 and usage tips.}

[codecov]

Codecov Report

❌ Patch coverage is 72.66667% with 41 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...-worker/src/studio/model/StudioPlayoutModelImpl.ts	40.00%	27 Missing ⚠️
...ckages/job-worker/src/playout/timeline/generate.ts	84.44%	7 Missing ⚠️
...c/playout/model/implementation/PlayoutModelImpl.ts	89.47%	6 Missing ⚠️
...-worker/src/playout/timings/timelineTriggerTime.ts	66.66%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[nytamin]

Sounds like a reasonable change to me.

Should we update the documentation of onRundownActivate / onRundownDeactivate to claify their capabilities while we're at it?

[nytamin]

Should this.#timelineNeedsRegeneration = false be moved into this.#regenerateStudioTimeline()?

Since this.#regenerateStudioTimeline() is async, this.#timelineNeedsRegeneration = false should be done in the beginning of that method, I think.

[Julusian]

I dont think it really makes a difference, as this is inside saveAllToDatabase which if anything else tries to modify the StudioPlayoutModel at the same time will be a race condition