microlinkhq / unavatar / 43082394890

98%

push

github

feat: proxy fallback for JSON API providers (#718)

* feat: proxy fallback for JSON API providers

JSON API providers called a plain got from the server's IP, so when an
upstream blocked it (zhihu 40352, bilibili -352) the provider returned
nothing and nothing was logged. Only HTML providers went through the
onFetchHTML hook that retries via the proxy tiers.

createApiProvider gives JSON providers the same hook. Each response is
classified before the getter decides: 404 or a getter NOT_FOUND stops
with no proxy tier spent, 403/429, a non-JSON 200 or a provider isBlocked
code throws so the next tier is tried, any other status >= 400 is retried
as an upstream error. got never retries on its own.

The hook is renamed onFetchHTML -> onFetch, and receives `kind` ('html' or
'api') so the consumer can tell them apart. Both helpers now map NOT_FOUND
to undefined at the provider boundary: before, a NOT_FOUND returned through
the hook reached avatar/auto and threw a TypeError interpolating the Symbol.

zhihu, bilibili, deezer and opencollective move to createApiProvider.

BREAKING: the core option onFetchHTML is now onFetch.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* fix: keep proxy fallback wired to onFetchHTML

The service still passes onFetchHTML, so renaming the option dropped every provider off the proxy hook. Lock the miss results that hook must not retry.

* test: lock an empty deezer picture that survives the artwork fallback

An empty picture_xl is discarded by the || chain, so the empty-string guard only sees an empty album cover.

* test: share the proxy-attempt capture and index stubs

The four provider suites and the two index loads repeated the same setup.

* docs: show that JSON getters receive NOT_FOUND from the factory

createApiProvider calls the getter with the response only, so passing getAvatar through directly would retry real misses.

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

1351 of 1413 branches covered (95.61%)

Branch coverage included in aggregate %.

265 of 265 new or added lines in 7 files covered. (100.0%)

4434 of 4486 relevant lines covered (98.84%)

8.64 hits per line