Live Runner - #3938
Merged
Merged
Conversation
* Don't create pub / sub trickle channels up front since those are now created on demand * Listen to the events channel for payments instead of pub channel
If a client needs to start publishing again and doesn't know where
it left off, then it can add a Lp-Trickle-Reset header along with
the -1 seq ("write next empty segment") which is already supported.
This will unblock any subscribers that may be waiting for hanging
writes from the previous publisher.
Also add a Lp-Trickle-Seq header so publishers can correctly position
their next segment in the stream.
Fix a bookkeeping bug in the LocalPublisher, and add tests.
Optionally add an auth callback to remote payment requests so operators can enforce policy checks before the remote signer sends down payments. When configured, the handler POSTs a JSON body containing the incoming request headers and the current signer state to the webhook URL right before encoding and signing. Configured auth headers are attached to the outbound request. Non-200 responses are propagated back to the caller through the existing API error envelope, preserving the upstream status code. New CLI flags: -remoteSignerWebhookUrl Webhook endpoint to call -remoteSignerWebhookHeaders Outbound auth headers (key:val,key2:val2) Omit -remoteSignerWebhookUrl to keep the existing behavior unchanged.
Allow the auth webhook to return an `expiry` field (Unix seconds) in its 200 response. The value is persisted in the signer's state and checked on subsequent requests. If the expiry hasn't yet passed, the webhook call is skipped. Once expired (or absent), auth resumes.
The runner only has the full URL and uses those when deleting streams.
This reverts commit 13a73ab.
The ja/serverless branch removed the /sign-byoc-job endpoint, breaking all BYOC inference (SDK gets 404 from signer, then BYOC orch rejects with "Could not verify job creds"). This restores the signing endpoint while preserving all new ja/serverless features (Daydream billing webhook auth, cached AuthExpiry, etc.). Cherry-picked from feat/remote-signer-byoc-v2: - SignBYOCJobRequest handler + route registration in remote_signer.go - BYOCJobSigningInput type + FlattenBYOCJob function in byoc/types.go Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Collaborator
Author
|
Closing the loop on a few things @rickstaa @ad-astra-video
I'm not sure how to do this in a general way without needing to configure the signer with every app on the network which doesn't seem practical. We can discuss after merge.
|
This was referenced Jul 22, 2026
Member
|
@j0sh thanks for handling my comments. Good to be merged from my side. I think the only outstanding PRs on the go-livepeer side for a release are: |
5 tasks
This was referenced Jul 22, 2026
This was referenced Jul 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This introduces LiveRunner as a way to run live AI applications behind a Livepeer orchestrator.
LiveRunner lets an orchestrator manage external runner processes for live AI workloads. A runner registers with the orchestrator, advertises its app, version, GPU, capacity, mode, and pricing metadata, and receives session traffic through orchestrator-proxied URLs. The runner’s internal URL is not exposed through discovery.
The orchestrator acts as the control plane for these runners. It tracks runner health and capacity, reserves and releases sessions, proxies client requests, forwards session credentials, and manages session-scoped trickle channels. Runners can be registered dynamically through heartbeats or configured statically from JSON.
The branch supports both persistent sessions and single-shot runner modes. Persistent sessions stay active until stopped, expired, released by health checks, or ended by payment failure. Single-shot runners reserve capacity for a single proxied request and release it when the request completes.
LiveRunner also adds the supporting discovery, payment, and trickle plumbing. Orchestrators expose runner metadata through
/discovery, remote signer discovery can merge and filter runner entries, and on-chain sessions can use payment challenges with recurring accounting. Trickle changes add explicit channel creation, publisher reset handling, sequence metadata, and improved buffering for live stream fanout.It also adds a Scope-specific serverless endpoint.
/scopestarts a live-video-to-video Scope session using control and events trickle channels, with support for serverless WebSocket workers, payment challenges when running on-chain, and a smaller request body surface tailored to Scope startup parameters.Summary by CodeRabbit
POST /registerLiveRunnersfor static registration./scopestreaming endpoint.