fix(youtube,tiktok): request identity encoding on the media reads

[giladresisi]

What kind of change does this PR introduce?

Bug fix.

Why was this change needed?

The customer report

A customer reported (Discord) that ~1 GB YouTube uploads through Postiz fail often enough that they built a heartbeat agent just to check whether their posts actually went out. Their own investigation was accurate: the same hosted files alternated between passing and failing without being changed, an immediately-failed post succeeded a minute later after restarting the same row, and larger files fail more often without there being a fixed size limit.

Root cause

YoutubeProvider.youtubeMediaSize / youtubeChunkStream and TiktokProvider.tiktokChunkStream read the stored video back from media storage with their own HEAD and ranged-GET helpers, and none of them asked for identity encoding. Every other media read in the project does — #1835 added accept-encoding: identity to SocialAbstract.mediaSize / mediaChunk / mediaStream and to the providers that read media themselves.

That header matters here for two reasons, both documented by Cloudflare:

• Cloudflare may transform (compress) a response, and when it does, "Cloudflare may remove the Content-Length HTTP header of responses delivered to website visitors". Which compression is applied is driven by "the values visitors provide in the accept-encoding request header" — so asking for identity is the client-side way to keep the response untransformed and its length intact. (The origin-side equivalent Cloudflare documents is cache-control: no-transform, which "must be set by the origin — it cannot be added in client requests".)
• With no Content-Length the edge cannot serve a byte range: "If the origin response does not include the Content-Length header, the cache will return the full content with an HTTP 200 response", instead of the 206 the uploader asked for.

A 200-with-full-body is currently thrown as BadBody, which postWorkflowV106 treats as a permanent platform rejection: the post is marked ERROR immediately with no retry. A 1 GB video needs ~128 ranged reads, so one such answer kills the whole post even though the YouTube upload session itself is still perfectly resumable. That matches the reported symptom, including why it scales with file size and why an identical file behaves differently between attempts.

Why the header was missing here

This looks like an artifact of PR merge ordering rather than a decision. #1813 introduced these bespoke YouTube/TikTok helpers on 2026-08-03. #1835 swept identity encoding across the project on 2026-08-04, but it had been written against a tree that did not yet contain them — so X and LinkedIn (which had their own bespoke ranged reads at the time, from #1796 and #1786) were consolidated onto the shared helpers and fixed, while YouTube and TikTok were missed. SocialAbstract and every provider that reads media through it has had the header since; these three call sites were the only ones left without it.

Other information:

• Scope: this PR only adds the header. Behaviour on a non-206 response is deliberately unchanged, so the fix is a prevention rather than a behaviour change, and its effect can be observed on its own.
• Please monitor after deploy. The customer symptom (large YouTube uploads intermittently going to ERROR with "The media storage did not return the requested byte range") should stop. If it recurs, the follow-up is to stop treating that specific answer as permanent: a documented 200-with-full-body would be thrown as a plain Error instead of BadBody, which the v1.0.6 workflow already knows how to handle — it re-probes the upload session and resumes from the exact committed byte offset, with a bounded consecutive-failure budget. That behaviour was prototyped and verified end-to-end against a storage server injecting Cloudflare-style 200s: pre-change the post died at the third chunk; with the reclassification the same upload survived five injected failures, resuming byte-exactly each time, and published in 98 s. It is being held back deliberately in favour of trying the smaller, in-pattern fix first.
• Suggested follow-ups (not included here):
  • Delete youtubeMediaSize and call SocialAbstract.mediaSize instead, as TikTok already does. The generic helper is a strict superset: it also rejects a non-ok HEAD and a zero/NaN length (a failed HEAD can still carry the Content-Length of its error body, which would poison the chunk-count math downstream).
  • Consolidate youtubeChunkStream / tiktokChunkStream into a single mediaChunkStream on SocialAbstract, next to mediaChunk (ranged, buffered) and mediaStream (whole file, streamed). The ranged-stream shape is the one combination the abstract does not offer today, which is why both providers hand-rolled it; a shared helper would have been swept automatically by fix: stream provider media uploads instead of buffering files in memory #1835 and would keep the non-206 classification in one place. Note the two callers do not want identical error semantics — YouTube can probe and resume its session, TikTok cannot — so the shared helper should throw one error type and let each caller classify it.

Checklist:

Put a "X" in the boxes below to indicate you have followed the checklist;

• I have read the CONTRIBUTING guide.
• I have signed the Contributor License Agreement (CLA) (ICLA for individuals, CCLA for entities).
• I confirm I have not used AI to submit this PR or generate code for it.
• I checked that there were no similar issues or PRs already open for this.
• This PR fixes just ONE issue

🤖 Generated with Claude Code

[postiz-agent]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.