fix(api): stop leaking the probe's skip_play_count into the stream url - #1027
Open
rickyrombo wants to merge 1 commit into
Open
fix(api): stop leaking the probe's skip_play_count into the stream url#1027rickyrombo wants to merge 1 commit into
rickyrombo wants to merge 1 commit into
Conversation
tryFindWorkingUrl probes each candidate host with a two-byte range request and
sets skip_play_count=true so the probe is not counted as a listen. It set that
on the candidate itself and then returned the same URL, so the flag rode along
into what the caller hands the client.
The node serving /tracks/cidstream/:cid returns early from logTrackListen when
it sees skip_play_count, so every play resolved through /v1/tracks/:id/stream
went unrecorded. Verified against production: the Location header from
/v1/tracks/{id}/stream carries skip_play_count=true today. The fallback path is
affected too, since the returned mainURL is urls[0] and was mutated by its own
probe attempt.
Probe on a copy and return the candidate untouched. redirectToStream still
honours an explicit skip_play_count from the caller.
Tests assert the returned URL is clean on the primary, fallback, and mirror
paths, and that the probe itself still sets the flag -- confirmed failing
against the previous behaviour.
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.
The bug
tryFindWorkingUrlprobes each candidate host with a two-byte range request, settingskip_play_count=trueso the probe isn't counted as a listen. But it sets that on the candidate itself:The node serving
/tracks/cidstream/:cidreturns immediately fromlogTrackListenwhen it sees that flag, so plays resolved through/v1/tracks/:id/streamare never recorded.Confirmed against production — the live
Locationheader today:The fallback path has it too:
mainURLisurls[0], already mutated on the first iteration, so even "no working host" returns a suppressed URL.This has been there since the endpoint was added (#57). In practice most playback resolves the track object's
streamMediaLink directly rather than calling this endpoint, which is why aggregate play counts look healthy — but any caller that does use/streamloses the play.The fix
Probe on a copy; return the candidate untouched.
redirectToStreamstill honours an explicitskip_play_countpassed by the caller, so opting out remains possible./v1/tracks/:id/downloadshares this helper and is fixed by the same change, though downloads don't hit thecidstreampath so no play was at stake there.Tests
Three, using an
httptestserver that records what the probe actually sent:skip_play_count, keeps itssignature, and the probe did send the flag (so probing still can't inflate counts)Confirmed failing against the previous behaviour: