Skip to content

fixes: Runner stream state inconsistencies - #1910

Open
joschahenningsen wants to merge 3 commits into
devfrom
fixes/runner
Open

fixes: Runner stream state inconsistencies#1910
joschahenningsen wants to merge 3 commits into
devfrom
fixes/runner

Conversation

@joschahenningsen

Copy link
Copy Markdown
Member

See individual commits for details.

Include the stream version in end-of-stream notifications so the
backend can track which version ended and only mark the stream
not-live once all versions have finished.
- Protect r.jobs and r.discard with a mutex to prevent concurrent map
  read/write crashes.
- Split notification retries: critical notifications (StreamEnd,
  StreamStart, VODReady) retry indefinitely with capped backoff until
  delivered or the runner shuts down. Non-critical notifications keep
  bounded retries.
- Cache the gRPC connection to the manager with keepalive parameters
  instead of creating a new connection per notification.
- Add 5 new DAO methods for per-version job tracking, stale stream
  detection, and orphaned job cleanup on runner re-registration.
- Fix EndStream to always set LiveNow=false regardless of whether
  individual runner jobs could be cancelled.
- Fix streamEnded to only mark a stream not-live after all versions
  have ended, not on the first StreamEndNotification.
- Guard TriggerDueStreams against launching duplicate jobs for the
  same stream+version.
- Add ReapStaleStreams to clean up streams stuck in live state when
  runners crash or notifications are permanently lost.
- Clean orphaned runner jobs when a runner re-registers.
- Register reapStaleStreams as a per-minute cron job.
@joschahenningsen joschahenningsen self-assigned this Aug 7, 2026
@joschahenningsen joschahenningsen added the bug Something isn't working label Aug 7, 2026

@kordianbruck kordianbruck left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good. I'm worried that this is risky in the sense of stopping properly working streams, but you added a decent amount of logging. The entire setup with job count is a rough abstraction for "is this stuff working properly", but it might get us there. IDK how much of this change I actually understand, but I would've hoped there was an easy path to not use mutex'es (but I assume that's fundamentally how one runner can process multiple streams).

No integration tests of course means you've properly smoke tested this yourself, right? 😉

Comment thread cmd/tumlive/main.go
// fetch live stream previews
_ = tools.Cron.AddFunc("fetchLivePreviews", api.FetchLivePreviews(daoWrapper), "*/1 * * * *")
// reap streams stuck in live state due to runner crash or lost notifications
_ = tools.Cron.AddFunc("reapStaleStreams", m.ReapStaleStreams, "*/1 * * * *")

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we reduce the frequency here? should suffice to run this every 30 minutes only during the day, right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants