[Bug] undici 8 broke my calendar

[rejas]

Environment

System Information

• SYSTEM: manufacturer: Apple Inc.; model: MacBookPro18,3; virtual: false; MM: v2.36.0-develop
• OS: platform: darwin; distro: macOS; release: 26.4; arch: arm64; kernel: 25.4.0
• VERSIONS: electron: 41.1.1; used node: 22.22.2; installed node: 22.22.2; npm: 10.9.7; pm2: 6.0.14
• ENV: XDG_SESSION_TYPE: undefined; MM_CONFIG_FILE: undefined
  WAYLAND_DISPLAY: wayland-1; DISPLAY: undefined; ELECTRON_ENABLE_GPU: undefined
• RAM: total: 32768.00 MB; free: 785.58 MB; used: 31982.42 MB
• OTHERS: uptime: 182 minutes; timeZone: Europe/Berlin

Which start option are you using?

node --run start

Are you using PM2?

No

Module

None

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?

updated my mirror after the latest release and got only one of my calendars to work...

What did you expect to happen?

calendar loads, just like the other

What actually happened?

[2026-04-05 21:56:38.958] [WARN] [http_fetcher] https://xxxxxxxx.de/caldav/kalender/prwvrm/ - Network error: fetch failed Retry #1 in 15s.
[2026-04-05 21:56:38.959] [ERROR] [calendar] Calendar Error. Could not fetch calendar: https://xxxxxxx.de/caldav/kalender/prwvrm/ Network error: fetch failed

Additional comments

strangely my other calendar from the same url works like a charm.... will look into this maybe, for now i downgrade undici to v7 on my setup

Participation

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

[KristjanESPERANTO]

I suspect this is caused by undici v8 changing the allowH2 default from false to true.

Could you check whether your calendars are served over HTTP/1.1 or HTTP/2?
And which server software is running (nginx, Apache, custom)?

Like this:

$ curl -sI --http2 https://ics.calendarlabs.com/76/mm3137/US_Holidays.ics 
HTTP/2 200 
x-powered-by: PHP/7.4.33
access-control-allow-origin: *
content-type: text/calendar;charset=UTF-8
date: Sun, 05 Apr 2026 20:56:02 GMT
server: Apache

[rejas]

Both calendars (working and non working) seem to return the same:

% curl -sI https://XXXX.de/caldav/kalender/vjaffe/
HTTP/2 401 
date: Tue, 07 Apr 2026 12:17:01 GMT
content-type: text/plain; ; charset="utf-8"
www-authenticate: Basic realm="Synology Calendar"

% curl -sI https://XXXX.de/caldav/kalender/home/  
HTTP/2 401 
date: Tue, 07 Apr 2026 12:17:49 GMT
content-type: text/plain; ; charset="utf-8"
www-authenticate: Basic realm="Synology Calendar"

As you can see, its running on a Synology NAS, where nginx is configured

[KristjanESPERANTO]

That blows my theory out of the window :-(

If we really do release a point release and can't find a solution before, we should downgrade to version 7 for that release.

[rejas]

Logging he actual error we get shows this:

  [cause]: InvalidArgumentError: invalid onRequestStart method
      at assertRequestHandler (/Users/veeck/Projekte/MagicMirror/node_modules/undici/lib/core/util.js:550:11)

[rejas]

oh, this is the culprit in my config, the failing calendar has "selfSignedCert: true (dont know hwy I adde dit there but not in the other)

[khassel]

I'm not sure if I understood the ... syntax correctly, and whether the changes I tested match the original code. With the modified code, it works with selfSignedCert: true.

diff --git a/js/http_fetcher.js b/js/http_fetcher.js
index 830b08b..517c645 100644
--- a/js/http_fetcher.js
+++ b/js/http_fetcher.js
@@ -263,9 +263,10 @@ class HTTPFetcher extends EventEmitter {
 		const timeoutId = setTimeout(() => controller.abort(), this.timeout);
 
 		try {
+			const opt = this.getRequestOptions();
+			opt.signal = controller.signal;
 			const response = await fetch(this.url, {
-				...this.getRequestOptions(),
-				signal: controller.signal
+				opt
 			});
 
 			if (!response.ok) {

[KristjanESPERANTO]

I think the root cause is that we're mixing two undici versions: Node's built-in one (global fetch()) and npm undici@8 (new Agent()). Their internal handler interfaces don't seem to match anymore, so passing an npm-undici Agent as dispatcher to global fetch() throws invalid onRequestStart method.

If that's really the case, using require("undici").fetch instead of global fetch() when we pass a dispatcher should fix it - so Agent and fetch come from the same package.

@khassel I think your patch with { opt } nests the options object instead of spreading them? That would silently drop the dispatcher, so selfSignedCert stops crashing but probably also stops actually working.

I think I'll find time tomorrow to dig into it a bit more and check my theory 😪

[khassel]

yes, replacing const { Agent } = require("undici"); with const { fetch, Agent } = require("undici"); works

[rejas]

you guys are great! thanks for handling all this network/server/library stuff!

[KristjanESPERANTO]

Thank you for your appreciative words! 🙂 I find problems like this kind of annoying, but also fascinating.

I woke up too early today, so I worked on it some more and created PR #4097.

[khassel]

This has now been merged, so @rejas, could you please check if it now works on develop and close this issue if necessary?