Issue Editing Calendar/Task Events with “At Time of Event” Notifications

Issues
1

Issue Description

Has anyone run into an issue where creating a calendar or task event with an “at time of event” notification causes problems? In my case, Bulwark can’t edit tasks created this way.

When it happens, I see the following error:

TypeError: Cannot read properties of undefined (reading '@type')

This appears in the stack trace and seems to break the edit flow in the UI.

Thunderbird handles these events without issue and they can be edited and deleted normally.

However with tasks Thunderbird also shows related problems and sometimes can’t even delete or properly access them. I also see errors like:

TypeError: can't access property "isInboxItem", this.mItemInfoCache[item.id] is undefined

and:

console.error: Invalid alarm for item: null
(VALARM with trigger PT0S)
NS_ERROR_ILLEGAL_VALUE in CalAlarm.sys.mjs

Eventually the calendar is even set to read-only:

Error code: 0x80004005
Description: ID for modifyItem item is null

Has anyone seen this behavior or found a workaround for events/tasks using “at time of event” alerts? After creating another task with “at time of event” notification, thunderbird is completely cut off from Calendar.

Reproduction Steps

  1. Create an event with at time of event notification.

Stalwart Version

v0.16.x

Installation Method

Docker

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

Internal

Additional Context

Bulwark
Thunderbird

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

This looks like a genuine bug worth filing on the Stalwart GitHub issue tracker. Here’s what the error chain is telling us:

Root cause (likely): A VALARM with trigger PT0S — meaning “at the exact time of the event” (zero offset) — is being parsed or round-tripped in a way that loses its @type field in the internal JSCalendar representation. When the WebUI (Bulwark) or the server then tries to read @type back, it gets undefined, breaking the edit flow.

The specific errors you’re seeing are consistent with this:

  • TypeError: Cannot read properties of undefined (reading '@type') — the alarm’s trigger object is present but @type has been dropped.
  • Invalid alarm for item: null / VALARM with trigger PT0S — Thunderbird is receiving back a VALARM it considers malformed, likely because the zero-duration trigger is being serialized in a way that iCalendar clients reject.
  • ID for modifyItem item is null — Thunderbird’s CalDAV layer ultimately gives up on items it can’t safely parse.

Workaround (short term): Use a small non-zero offset for “at time of event” notifications — e.g. PT1S (1 second before) instead of PT0S. This avoids the zero-duration trigger while still being functionally immediate.

What to do next:

  1. Please open a bug report on the Stalwart GitHub repository with the reproduction steps you’ve already documented here. Include the exact VALARM iCalendar snippet and the version (v0.16.x). The PT0S trigger is a valid iCalendar construct and should be handled correctly.
  2. A Stalwart team member or community contributor will need to look at how PT0S VALARM triggers are being converted to/from JSCalendar OffsetTrigger objects to confirm where the @type is being lost.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong. If you found it useful, mention @helpbot in any reply to ask follow-up questions and the bot will respond again.