[Bug] Weather fetch loop in error recovery

[sdetweil]

Environment

MagicMirror² version:
Node version:
npm version:
Platform:

Which start option are you using?

node --run start

Are you using PM2?

No

Module

weather

Have you tried disabling other modules?

• Yes
• No

Have you searched if someone else has already reported the issue on the forum or in the issues?

• Yes

What did you do?

Details

user reported in forum
https://forum.magicmirror.builders/post/130815

when the weather provider fetch fails, error recovery goes into a loop

Configuration

{
                        module: "weather",
                        position: "top_right",
                        config: {
                                weatherProvider: "openmeteo",
                                type: "current",
                                tempUnits: "metric",
                                lat: 50.4667,
                                lon: 7.6333,
                                useKmh: true, 
                                updateInterval: 20 * 60 * 1000,
                        }
                },
                {
                        module: "weather",
                        position: "top_right",
                        header: "Wetter Vorhersage",
                        config: {
                                weatherProvider: "openmeteo",
                                type: "forecast",
                                lat: 50.4667,
                                lon: 7.6333,
                                useKmh: true, 
                                updateInterval: 20 * 60 * 1000,
                        }
                },

<!-- Paste relevant code here -->

Steps to reproduce the issue:

What did you expect to happen?

no error, maybe UI notification

What actually happened?

worked for a while, then encountered an error (not reported) but looped in fetch , notice the timestamps

[18.04.2026 10:15:22.453] [INFO]  [http_fetcher] [weatherprovider.openmeteo] Fetching url: https://api.open-meteo.com/v1/forecast?latitude=50.4667&longitude=7.6333...
[18.04.2026 10:15:22.510] [INFO]  [http_fetcher] [weatherprovider.openmeteo] Fetching url: https://api.open-meteo.com/v1/forecast?latitude=50.4667&longitude=7.6333...
[18.04.2026 10:15:22.622] [INFO]  [http_fetcher] [weatherprovider.openmeteo] Fetching url: https://api.open-meteo.com/v1/forecast?latitude=50.4667&longitude=7.6333...

Additional comments

No response

Participation

• I am willing to submit a pull request for this change.

[sdetweil]

[CodeLine9]

Looking into this — the network error backoff in HTTPFetcher caps the retry delay at a short fixed value (15s × 2^(maxRetries-1) = 60s) instead of falling back to the configured updateInterval after retries are exhausted. This causes retries every 60s even when the user configured a 20-minute interval. Happy to submit a fix.

[sdetweil]

the logs show subsecond times between tries (100-150ms)

[KristjanESPERANTO]

Does this happen on the develop branch as well?

[sdetweil]

do not know.. will ask use to try that first

[KristjanESPERANTO]

Yes, #4092 should already fix this and the approach of the new PR #4110 would add a bit polishing 🙂

[sdetweil]

#4092 is the identifier change, was there some other fix for error handling?

[KristjanESPERANTO]

No, there wasn't a separate error handling fix - the identifier fix in #4092 should actually cover this. The duplicate identifiers caused new fetchers to be created on each retry, each starting with a fresh counter. That's likely why the logs showed sub-second intervals: backoff never had a chance to build up.

That said, the backoff logic itself still has a small gap (capping at 60s instead of falling back to the configured interval after exhaustion). #4113 (as replacement for #4110) addresses that part.

[Phantomkommander]

Hi everyone,

I wanted to jump in and give some positive feedback on the new weather module logic in the develop branch.

My tablet recently developed a life of its own, triggering constant reloads and connection drops. In the past, this would have instantly nuked my API limit for the day. Thanks to the new protection logic, my setup stayed alive and didn't get banned! It’s a huge improvement for stability.

Thanks for the hard work on this! Everything is running smoothly now.

[sdetweil]

@Phantomkommander . Thanks for the update.
I see on the forum you noticed a condition where a new client doesn't get any data for a while if the module is in error recovery.