[core] refactor: extract and centralize HTTP fetcher

[KristjanESPERANTO]

Summary

PR #3976 introduced smart HTTP error handling for the Calendar module. This PR extracts that HTTP logic into a central HTTPFetcher class.

Calendar is the first module to use it. Follow-up PRs would migrate Newsfeed and maybe even Weather.

Before this change:

• ❌ Each module had to implemented its own fetch() calls
• ❌ No centralized retry logic or backoff strategies
• ❌ No timeout handling for hanging requests
• ❌ Error detection relied on fragile string parsing

What this PR adds:

• ✅ Unified HTTPFetcher class with intelligent retry strategies
• ✅ Modern AbortController with configurable timeout (default 30s)
• ✅ Proper undici Agent for self-signed certificates
• ✅ Structured error objects with translation keys
• ✅ Calendar module migrated as first consumer
• ✅ Comprehensive unit tests with msw (Mock Service Worker)

Architecture

Before - Decentralized HTTP handling:

Calendar Module          Newsfeed Module         Weather Module
┌─────────────┐         ┌─────────────┐         ┌─────────────┐
│ fetch() own │         │ fetch() own │         │ fetch() own │
│ retry logic │         │ basic error │         │ no retry    │
│ error parse │         │   handling  │         │ client-side │
└─────────────┘         └─────────────┘         └─────────────┘
      │                       │                       │
      └───────────────────────┴───────────────────────┘
                              ▼
                        External APIs

After - Centralized with HTTPFetcher:

┌─────────────────────────────────────────────────────┐
│                  HTTPFetcher                        │
│  • Unified retry strategies (401/403, 429, 5xx)     │
│  • AbortController timeout (30s)                    │
│  • Structured errors with translation keys          │
│  • undici Agent for self-signed certs               │
└────────────┬──────────────┬──────────────┬──────────┘
             │              │              │
     ┌───────▼───────┐ ┌────▼─────┐ ┌──────▼──────┐
     │   Calendar    │ │ Newsfeed │ │   Weather   │
     │   ✅ This PR  │ │  future  │ │   future    │
     └───────────────┘ └──────────┘ └─────────────┘
             │              │              │
             └──────────────┴──────────────┘
                          ▼
                   External APIs

Complexity Considerations

Does HTTPFetcher add complexity?

Even if it may look more complex, it actually reduces overall complexity:

• Calendar already has this logic (PR [calendar] fix: prevent excessive fetching on client reload and refactor calendarfetcherutils.js #3976) - we're extracting, not adding
• Alternative is worse: Each module implementing own logic = 3× the code
• Better testability: 443 lines of tests once vs. duplicating tests for each module
• Standards-based: Retry-After is RFC 7231, not custom logic

Future Benefits

Weather migration (future PR):

Moving Weather from client-side to server-side will enable:

• Same robust error handling - Weather gets 429 rate-limiting, 5xx backoff for free
• Simpler architecture - No proxy layer needed

Moving the weather modules from client-side to server-side will be a big undertaking, but I think it's a good strategy. Even if we only move the calendar and newsfeed to the new HTTP fetcher and leave the weather as it is, this PR still makes sense, I think.

Breaking Changes

None

---

I am eager to hear your opinion on this 🙂

[rejas]

Awesome idea, I really like!

Just one thing: We dont add the default english translations to other languages. If a translation isnt available, it automatically takes the english one.

[KristjanESPERANTO]

My idea was to make it easier for the translators, but you're right, that was not very clean. Instead of taking the easy way out and simply removing them, I used automatic translation (which has delivered very good results in the past) to translate the strings. In doing so, I even noticed duplicate strings in the pt translation, which I removed right away.

[khassel]

This broke my calendar:

[2026-01-22 23:27:21.769] [ERROR] [calendar] https://calendar.google.com/calendar/ical/xxx.calendar.google.com/public/basic.ics - iCal parsing failed: UNTIL rule part MUST have the same value type as DTSTART 

[2026-01-22 23:27:21.770] [ERROR] [calendar] Calendar Error. Could not fetch calendar:  https://calendar.google.com/calendar/ical/xxx.calendar.google.com/public/basic.ics iCal parsing failed: UNTIL rule part MUST have the same value type as DTSTART 

[khassel]

Found the breaking entry:

DTSTART;VALUE=DATE:20160313
DTEND;VALUE=DATE:20160314
RRULE:FREQ=YEARLY;UNTIL=20190312;BYMONTHDAY=13;BYMONTH=3
DTSTAMP:20260122T223427Z
UID:a21aa3d4-c1c2-4d74-b929-535e168a566f
CREATED:20170127T230833Z
LAST-MODIFIED:20190330T190642Z
SEQUENCE:1
STATUS:CONFIRMED
SUMMARY:xxx
TRANSP:OPAQUE
X-MOZ-FAKED-MASTER:1
X-MOZ-GENERATION:2
END:VEVENT

I was able to solve the problem by deleting and recreating the entire calendar series in Google Calendar, but other users might encounter similar issues...

[KristjanESPERANTO]

Oh. I'll take a look at it by the weekend at the latest.

[khassel]

don't know if it is a real problem, that was the only entry with a RRULE in my birthday calendar and the UNTIL=20190312 was in the past ...

[sdetweil]

I think it is confused between full day and not for some reason, rrule until doesn’t use DATE: as it’s not required there

[KristjanESPERANTO]

I think I found the root cause 🙂

The error comes from rrule-temporal v1.4.2, which added yesterday stricter RFC 5545 validation. The library now correctly enforces that UNTIL must match DTSTART's type - if DTSTART is a DATE (all-day event), UNTIL must also be a DATE.

The problem: node-ical never told rrule-temporal that DTSTART was VALUE=DATE, so the validation failed. The stricter validation is good - it just exposed a bug in node-ical that's been there all along.

Recreating the entry helped because Google Calendar probably removed the UNTIL or changed the format. But the underlying issue remains for other users with similar entries.

I've opened a fix: jens-maus/node-ical#432

This should handle Google Calendar birthdays and similar recurring all-day events correctly.