fix(frame_processor): surface empty pipeline_ids error to client + fallback to loaded pipelines#683
Conversation
…llback to loaded pipelines
When start() is called with no pipeline_ids:
1. Attempt a graceful fallback: if the pipeline_manager has loaded pipelines,
use those instead of erroring out. This matches the documented schema
behaviour ('If not provided, uses the currently loaded pipeline') and
prevents the error entirely for sessions that omit pipeline_ids but have
pipelines already loaded.
2. If still empty after the fallback, fire notification_callback with
type='stream_stopped' + error_message before returning, so the frontend
receives the failure via the WebRTC data channel instead of silently
hanging and retrying in a loop.
Previously the error was logged and published to Kafka only, making it
invisible to the client and triggering the retry/reconnect loop observed in
issue #680 (3 hits on the same fal job in one session).
Closes #680
Signed-off-by: livepeer-robot <robot@livepeer.org>
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Comment Tip CodeRabbit can enforce grammar and style rules using `languagetool`.Configure the |
🚀 fal.ai Preview Deployment
TestingConnect to this preview deployment by running this on your branch: 🧪 E2E tests will run automatically against this deployment. |
✅ E2E Tests passed
Test ArtifactsCheck the workflow run for screenshots. |
1 participant
Problem
Issue #680:
frame_processorsilently fails when started with nopipeline_ids, logging an ERROR server-side but never notifying the client. This left the frontend with no video output and no explanation — causing a retry/reconnect loop (3 hits on the same fal job in issue #680).Root cause
In
FrameProcessor.start(), the early-exit path for missingpipeline_idspublished a Kafka error event and setrunning = False, but never callednotification_callback. The client's data channel received no signal, so it retried.Changes
1. Graceful fallback — use loaded pipelines when none specified (new behaviour)
If
pipeline_idsis absent/empty ininitial_parameters, the processor now queriespipeline_manager.get_loaded_pipeline_ids()and uses whatever is already loaded. This matches the documented schema behaviour:This prevents the error entirely for sessions that legitimately omit
pipeline_ids.2. Surface error to client via data channel (bug fix)
If the fallback also yields nothing, the existing error path now calls
notification_callbackwith{"type": "stream_stopped", "error_message": "No pipeline IDs provided, cannot start"}before returning. The frontend receives this on the data channel and can show a user-visible error instead of retrying blindly.Testing
pipeline_idsis providedCloses #680