trickle: Add a /<channel>/next endpoint#3925
Merged
Merged
Conversation
Extracted from #3884 ("Serverless"). The /next route is independent of the WebSocket / Serverless work in that PR and can land on its own to unblock the livepeer-python-gateway SDK, whose TricklePublisher probes /next to learn nextWrite before its first POST (see livepeer/livepeer-python-gateway#12). Server registers GET /{streamName}/next, returning nextWrite as plain text + Lp-Trickle-Latest header. Returns 404 if the channel doesn't exist; sets Lp-Trickle-Closed: terminated when the channel is closed. Original commit: 8da1c69 on the ja/serverless branch. Extraction (commit message + omission of the Lp-Trickle-Reset hunk that travelled with the original) by Rick Staa, opened on Josh's behalf to unblock dependent SDK work.
fe74a11 to
5d82a42
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3925 +/- ##
===================================================
+ Coverage 32.87450% 32.88179% +0.00729%
===================================================
Files 171 171
Lines 42063 42078 +15
===================================================
+ Hits 13828 13836 +8
- Misses 27194 27199 +5
- Partials 1041 1043 +2
... and 6 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
3 tasks
rickstaa
added a commit
that referenced
this pull request
May 8, 2026
Mirror the Python SDK's first-POST flow in the Go publisher:
GET {baseURL}/next to learn the server's nextWrite, fall back to slot 0
on probe failure. Establishes a single canonical pattern across the two
trickle clients in the Livepeer stack.
Wire behavior on a fresh channel is unchanged — both old (always-0) and
new (probe-then-resolve) paths POST to /0 first, then /1, /2, ...
The probe adds one round-trip on session start; against a server with
the /next route (#3925) it returns nextWrite cleanly,
against a server without it (today's master) the failure path resolves
to 0 — the same starting slot.
The fallback explicitly returns 0 (not -1) for the same reason the
Python SDK does: -1 would let the server resolve to nextWrite, but the
publisher has no read-back path to learn what slot the server picked.
The local counter then increments past whatever the server chose,
causing the second POST to race the first at slot 0. Returning 0 keeps
the publisher's local counter in lockstep with the server.
Tests in trickle_test.go cover both paths via mock /next handlers
(success returning Lp-Trickle-Latest, fallback returning 400). The
existing test suite continues to pass against the configured trickle
server (which doesn't have /next on master) since the fallback path is
the existing behavior in disguise.
Refs #3925, livepeer/livepeer-python-gateway#12.
rickstaa
added a commit
that referenced
this pull request
May 8, 2026
Mirror the Python SDK's first-POST flow in the Go publisher:
GET {baseURL}/next to learn the server's nextWrite, fall back to slot 0
on probe failure. Establishes a single canonical pattern across the two
trickle clients in the Livepeer stack.
Wire behavior on a fresh channel is unchanged — both old (always-0) and
new (probe-then-resolve) paths POST to /0 first, then /1, /2, ...
The probe adds one round-trip on session start; against a server with
the /next route (#3925) it returns nextWrite cleanly,
against a server without it (today's master) the failure path resolves
to 0 — the same starting slot.
The fallback explicitly returns 0 (not -1) for the same reason the
Python SDK does: -1 would let the server resolve to nextWrite, but the
publisher has no read-back path to learn what slot the server picked.
The local counter then increments past whatever the server chose,
causing the second POST to race the first at slot 0. Returning 0 keeps
the publisher's local counter in lockstep with the server.
Tests in trickle_test.go cover both paths via mock /next handlers
(success returning Lp-Trickle-Latest, fallback returning 400). The
existing test suite continues to pass against the configured trickle
server (which doesn't have /next on master) since the fallback path is
the existing behavior in disguise.
Refs #3925, livepeer/livepeer-python-gateway#12.
Member
Author
|
@j0sh quick fix to make livepeer-python-gateway PR #7 compatible with the go-livepeer side. I didn’t aim for full code parity yet, but it might make sense to move both the Python and Go trickle subscribers into a separate shared package so they don’t diverge over time. Curious to hear what you think. |
j0sh
approved these changes
May 11, 2026
rickstaa
added a commit
to livepeer/livepeer-python-gateway
that referenced
this pull request
May 13, 2026
…erged The /<channel>/next trickle endpoint that this example depended on landed in livepeer/go-livepeer#3925 (merged 2026-05-12). The pre-merge custom tag :trickle-next-endpoint is no longer needed. Verified via test.sh: 11 detection records (person matches) + 4 transcript records (country matches) — full e2e flow passes against :master. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
rickstaa
added a commit
to livepeer/livepeer-python-gateway
that referenced
this pull request
May 13, 2026
…25 merged The /<channel>/next trickle endpoint that this example depended on landed in livepeer/go-livepeer#3925 (merged 2026-05-12). The pre-merge custom tag :trickle-next-endpoint is no longer needed. Verified via test.sh: 6 transcript records on the data channel ("country" match). Orchestrator + gateway logs show all trickle channels (events, out, data, control) using the next-endpoint without errors. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
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.
Extracted from #3884 — a small, independent piece that unblocks the livepeer-python-gateway pipeline SDK without waiting for the rest of the "Serverless" work.
What this adds
GET /{streamName}/nextreturns the channel's currentnextWrite:Lp-Trickle-Latest: {seq}Lp-Trickle-Closed: terminatedif the channel is closedWhy now
The Python SDK (livepeer-python-gateway) probes
/nextto learnnextWritebefore its first POST so it doesn't collide with the server's own-1-resolves-to-slot-0 behavior. Without this endpoint on master, the SDK's probe fails (the path matches the{idx}route, fails to parse"next"as an int, returns 400) and the publisher's fallback drops the first segment on every channel.Companion SDK fallback fix: livepeer/livepeer-python-gateway#14
Bug context: livepeer/livepeer-python-gateway#12
Relationship to #3884
Cherry-picked from commit
8da1c69224a866386770927de30f43bb565508cfon theja/serverlessbranch. The Lp-Trickle-Reset hunk inhandlePostthat travelled with that commit on the branch belongs to a separate "trickle: Support publisher resets" feature and was excluded here — landing it would expand scope beyond what the SDK needs.When #3884 lands, this commit will already be on master; the rebase should be clean.
Co-author
Original code by @j0sh — preserved as commit author. Extraction + adapted commit message by Rick Staa, with this PR opened on Josh's behalf to unblock dependent SDK work.
Test plan
go build ./trickle/...passesgo test ./trickle/...passes:trickle-next-endpointorchestrator image, point the SDK at it, confirmlive_transcribedelivers transcripts 0–3 (vs. the current 0, 2, 3 due to the slot-0 race)🤖 Generated with Claude Code