Covers over maxBodyBytes (4 MiB) can never be filled by the Poll #71

New Issue

2026-08-10T10:12:36+07:00

sulthan commented

2026-08-10 10:12:36 +07:00

Finding

Observed during the #61 manual verification (2026-08-10, local stack, this branch): a Series whose cover image is larger than maxBodyBytes (4 MiB, backend/internal/latest/fetch.go) can never acquire a Cover server-side.

TLSCoverFetcher.Fetch (backend/internal/latest/cover.go) rejects any cover with ContentLength > maxBodyBytes (and any body that actually reads past the cap). The error is logged against the Series and swallowed — the Series stays blank forever, and the fetch is retried on every due cycle. Not a #61 defect: the failure-isolation path works as designed. It is a ceiling question.

Live example

a-dragonslayers-peerless-regression on asura: og:image is a 8,571,192-byte GIF (cdn.asurascans.com). Log:

latest poll "asura:a-dragonslayers-peerless-regression": fetch cover https://cdn.asurascans.com/asura-images/covers/a-dragonslayers-peerless-regression.gif: fetch cover: response exceeds 4194304 bytes
latest poll "asura:a-dragonslayers-peerless-regression": latest is now Chapter 97

Cover rejected; chapter poll unaffected (good). The Series keeps a monogram in the UI indefinitely.

Options to consider

Raise the cap for cover fetches (covers are one bounded asset, not attacker-fed text — a dedicated, larger limit could be justified).
Downscale/transcode at fetch time (bigger change; ASURA serves 2000x2897 webp variants elsewhere too).
Leave as-is and accept large-cover series stay blank (document it).
Per-site override if only some sites serve huge assets.

Out of scope

Not closing anything; #61 and #55 are untouched.
This does not block the #61 manual verification — that used a smaller-cover Series (absolute-regression, 615 KB webp) and passed.

Triage notes

Reproducible from the current branch with any Series whose cover exceeds 4 MiB.
The cover pipeline as a whole is #55's territory; this may fold into it.

## Finding Observed during the #61 manual verification (2026-08-10, local stack, this branch): a Series whose cover image is larger than `maxBodyBytes` (4 MiB, `backend/internal/latest/fetch.go`) can never acquire a Cover server-side. `TLSCoverFetcher.Fetch` (`backend/internal/latest/cover.go`) rejects any cover with `ContentLength > maxBodyBytes` (and any body that actually reads past the cap). The error is logged against the Series and swallowed — the Series stays blank forever, and the fetch is retried on every due cycle. Not a #61 defect: the failure-isolation path works as designed. It is a ceiling question. ## Live example `a-dragonslayers-peerless-regression` on asura: og:image is a 8,571,192-byte GIF (cdn.asurascans.com). Log: ``` latest poll "asura:a-dragonslayers-peerless-regression": fetch cover https://cdn.asurascans.com/asura-images/covers/a-dragonslayers-peerless-regression.gif: fetch cover: response exceeds 4194304 bytes latest poll "asura:a-dragonslayers-peerless-regression": latest is now Chapter 97 ``` Cover rejected; chapter poll unaffected (good). The Series keeps a monogram in the UI indefinitely. ## Options to consider - Raise the cap for cover fetches (covers are one bounded asset, not attacker-fed text — a dedicated, larger limit could be justified). - Downscale/transcode at fetch time (bigger change; ASURA serves 2000x2897 webp variants elsewhere too). - Leave as-is and accept large-cover series stay blank (document it). - Per-site override if only some sites serve huge assets. ## Out of scope - Not closing anything; #61 and #55 are untouched. - This does not block the #61 manual verification — that used a smaller-cover Series (`absolute-regression`, 615 KB webp) and passed. ## Triage notes - Reproducible from the current branch with any Series whose cover exceeds 4 MiB. - The cover pipeline as a whole is #55's territory; this may fold into it.

sulthan added the needs-triage label 2026-08-10 10:12:36 +07:00

sulthan referenced this issue

2026-08-11 09:33:04 +07:00

Record the lightnovelworld series-identity decision (#77) #81

sulthan referenced this issue from a commit

2026-08-11 09:34:29 +07:00

Record the lightnovelworld series-identity decision (#77) (#81)

sulthan referenced this issue from a commit

2026-08-17 12:05:47 +07:00

fix: give covers their own 10 MiB byte cap (#71)

sulthan referenced a pull request that will close this issue

2026-08-17 12:06:04 +07:00