Summary
In MagicMirror v2.35.0, the yr weather provider has explicit logic to handle 304 Not Modified responses and reuse cached data, but js/http_fetcher.js still routes all non-OK responses into the error path.
That means a 304 response never reaches defaultmodules/weather/providers/yr.js, even though the provider is written to handle it.
Affected Version
- Confirmed locally on
v2.35.0 (d05ea751)
Evidence
Provider expects 304
defaultmodules/weather/providers/yr.js contains logic like:
action on response:
if (response.status === 304) {
use cached data
return
}
Core fetcher blocks 304
Unpatched js/http_fetcher.js in v2.35.0 currently behaves like:
if (!response.ok) {
this.emit("error", errorInfo)
} else {
this.emit("response", response)
}
Since response.ok is false for HTTP 304, the response is treated as an error instead of being emitted to the provider.
Why This Matters
yr sends cache-aware responses.
- The provider already contains
304 reuse logic.
- The core fetcher prevents that logic from running.
- Result:
304 Not Modified behaves like an error instead of a cache hit.
Minimal Fix
Allow 304 to flow through the normal response event so cache-aware providers can decide what to do:
if (response.status === 304) {
this.emit("response", response)
} else if (!response.ok) {
const { delay, errorInfo } = this.#getDelayForResponse(response)
nextDelay = delay
this.emit("error", errorInfo)
} else {
this.emit("response", response)
}
Expected Behavior
When the upstream server returns 304 Not Modified, providers that are built to reuse cached data should receive that response and handle it themselves.
Actual Behavior
HTTPFetcher classifies 304 as an error before the provider sees it.
Local Impact
This was observed while using the built-in weather yr provider with cache headers and existing cached weather data. The local workaround is a small patch to js/http_fetcher.js that lets 304 responses reach the provider.
Summary
In MagicMirror
v2.35.0, theyrweather provider has explicit logic to handle304 Not Modifiedresponses and reuse cached data, butjs/http_fetcher.jsstill routes all non-OK responses into the error path.That means a
304response never reachesdefaultmodules/weather/providers/yr.js, even though the provider is written to handle it.Affected Version
v2.35.0(d05ea751)Evidence
Provider expects
304defaultmodules/weather/providers/yr.jscontains logic like:Core fetcher blocks
304Unpatched
js/http_fetcher.jsinv2.35.0currently behaves like:Since
response.okis false for HTTP304, the response is treated as an error instead of being emitted to the provider.Why This Matters
yrsends cache-aware responses.304reuse logic.304 Not Modifiedbehaves like an error instead of a cache hit.Minimal Fix
Allow
304to flow through the normalresponseevent so cache-aware providers can decide what to do:Expected Behavior
When the upstream server returns
304 Not Modified, providers that are built to reuse cached data should receive that response and handle it themselves.Actual Behavior
HTTPFetcherclassifies304as an error before the provider sees it.Local Impact
This was observed while using the built-in weather
yrprovider with cache headers and existing cached weather data. The local workaround is a small patch tojs/http_fetcher.jsthat lets304responses reach the provider.