An upstream body whose first bytes are not those of the format its Content-Type names (a JPEG sent as image/png, text, an empty body) answered 500 on both image routes, was logged at error level, and was fetched again on every request.
Both routes now answer 415 unsupported source format, as for a Content-Type that is not a source format.
The image service logs it at warning level as source refused, with the Content-Type. Neither route logs it at error level any more.
It gets a negative cache entry, as an upstream error status does. For 5 minutes pixa does not fetch that source URL again, and a request that would need that fetch answers 502. README.md says so under Routes and where it lists the source formats.
Not shown by the diff:
The entry records 415, but a negative cache hit answers 502 whatever the entry records, as before.
Storing the entry, with its warning on failure, moved into storeNegative, which both failure points call, so fetchAndProcess stays under the function length limit.
Test changed under #280 (comment): the case "source fails the magic byte check" of TestService_Get_ConcurrentMissesShareAFailure now expects the negative cache.
Judgement call: a body under 12 bytes (magic.ErrNotEnoughData, the third error the same check returns) is handled the same way. The plan named only the other two.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/pixa/issues/253.
An upstream body whose first bytes are not those of the format its `Content-Type` names (a JPEG sent as `image/png`, text, an empty body) answered 500 on both image routes, was logged at error level, and was fetched again on every request.
- Both routes now answer 415 `unsupported source format`, as for a `Content-Type` that is not a source format.
- The image service logs it at warning level as `source refused`, with the `Content-Type`. Neither route logs it at error level any more.
- It gets a negative cache entry, as an upstream error status does. For 5 minutes pixa does not fetch that source URL again, and a request that would need that fetch answers 502. `README.md` says so under Routes and where it lists the source formats.
Not shown by the diff:
- The entry records 415, but a negative cache hit answers 502 whatever the entry records, as before.
- Storing the entry, with its warning on failure, moved into `storeNegative`, which both failure points call, so `fetchAndProcess` stays under the function length limit.
Test changed under https://git.eeqj.de/sneak/pixa/issues/280#issuecomment-151029: the case "source fails the magic byte check" of `TestService_Get_ConcurrentMissesShareAFailure` now expects the negative cache.
Judgement call: a body under 12 bytes (`magic.ErrNotEnoughData`, the third error the same check returns) is handled the same way. The plan named only the other two.
Model: opus-5-5
Both image routes must answer 415 for an upstream body whose first
bytes are not those of the format its Content-Type names, log it as a
refused source and not at error level, and answer the next request for
that source 502 without fetching it again. The test fails until the
fix for #253.
Model: opus-5-5
A body whose first bytes are not those of the format its Content-Type
names answered 500 on both image routes, was logged as pixa's own
error, and was fetched again on every request. Both routes now answer
415 for each error the first-bytes check returns, and the image service
logs the refused source at warning level. The failure also gets a
negative cache entry, as an upstream error status does, so the source
URL is not fetched again for 5 minutes, and meanwhile an image that
would need that fetch answers 502. README.md says so.
The case of TestService_Get_ConcurrentMissesShareAFailure that expected
such a source to be fetched again now expects the negative cache, as
#280 (comment) allows.
Model: opus-5-5
Rework: rebased onto next. The case of TestService_Get_ConcurrentMissesShareAFailure changed in the fix commit, under #280 (comment). next now refuses a request from the negative cache only when its image would need a fetch, so README.md, the TODO.md entry (moved to the top of Completed Steps) and the PR body now say that for this case too.
Model: opus-5-5
Rework: rebased onto `next`. The case of `TestService_Get_ConcurrentMissesShareAFailure` changed in the fix commit, under https://git.eeqj.de/sneak/pixa/issues/280#issuecomment-151029. `next` now refuses a request from the negative cache only when its image would need a fetch, so `README.md`, the `TODO.md` entry (moved to the top of Completed Steps) and the PR body now say that for this case too.
Model: opus-5-5
PASS: the change does what the plan on #253 (comment) settles on both image routes, and its one change to an existing test stays within #280 (comment).
Judgement call accepted: a body under 12 bytes (magic.ErrNotEnoughData) is handled like the other two first-bytes errors.
Model: opus-5-5
PASS: the change does what the plan on https://git.eeqj.de/sneak/pixa/issues/253#issuecomment-141533 settles on both image routes, and its one change to an existing test stays within https://git.eeqj.de/sneak/pixa/issues/280#issuecomment-151029.
Judgement call accepted: a body under 12 bytes (`magic.ErrNotEnoughData`) is handled like the other two first-bytes errors.
Model: opus-5-5
clawbot
merged commit 4fb6350aa1 into next2026-10-20 14:40:52 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Fixes #253.
An upstream body whose first bytes are not those of the format its
Content-Typenames (a JPEG sent asimage/png, text, an empty body) answered 500 on both image routes, was logged at error level, and was fetched again on every request.unsupported source format, as for aContent-Typethat is not a source format.source refused, with theContent-Type. Neither route logs it at error level any more.README.mdsays so under Routes and where it lists the source formats.Not shown by the diff:
storeNegative, which both failure points call, sofetchAndProcessstays under the function length limit.Test changed under #280 (comment): the case "source fails the magic byte check" of
TestService_Get_ConcurrentMissesShareAFailurenow expects the negative cache.Judgement call: a body under 12 bytes (
magic.ErrNotEnoughData, the third error the same check returns) is handled the same way. The plan named only the other two.Model: opus-5-5
clawbot referenced this pull request2026-10-19 06:12:53 +02:00
6ebb6ed618to985a6bb3fcRework: rebased onto
next. The case ofTestService_Get_ConcurrentMissesShareAFailurechanged in the fix commit, under #280 (comment).nextnow refuses a request from the negative cache only when its image would need a fetch, soREADME.md, theTODO.mdentry (moved to the top of Completed Steps) and the PR body now say that for this case too.Model: opus-5-5
PASS: the change does what the plan on #253 (comment) settles on both image routes, and its one change to an existing test stays within #280 (comment).
Judgement call accepted: a body under 12 bytes (
magic.ErrNotEnoughData) is handled like the other two first-bytes errors.Model: opus-5-5