Open machawk1 opened 2 years ago
Maybe because we are using the built built-in aborter in content.js?
return window.fetch(url, options)
.then(setTimeout(() => { aborter.abort() }, timeout))
.catch(error => {
log(`${url} appears to be down, incrementing host counter`)
log(error)
hostI += 1
})
The 502 is likely occurring before the AbortController fires, hence no catch.
There is nothing in the associated then (when added) that I am able to tell that distinguishes a successful response from a failed (502).
XHR is not a solution here, as fetch will only be allowed in manifest v3. (#316)
"Fetch detects only network errors. Other errors (4xx, 5xx) should be manually caught and rejected."
The ODUCS aggregator is alive again and this issue is not yet fixed. A mock would be useful here for testing.
See #316 for some additional work on this front in adapting the extension to MV3.
The default aggregator at memgator.cs.odu.edu is currently returning an HTTP 502. The logic for aggregator fall-through uses fetch, which will not invoke the catch to handle the error, thus the flow never resolves.
fetch should be returning a promise. We are returning
window.fetch
but somehow detection of this broken promise is not caught in the instance of this HTTP status code. Timely handling of this issue is needed before the default aggregator becomes alive again.