CalendarEvent/set does not persist useDefaultAlerts: false

Issues
1

Issue Description

CalendarEvent/set does not persist useDefaultAlerts: false.

An event created or updated with useDefaultAlerts: false is subsequently returned by CalendarEvent/get with useDefaultAlerts: true.

This is also reproducible against current Stalwart main.

Expected Behavior

Per the JMAP Calendars specification, useDefaultAlerts is an optional Boolean with a default value of false.

When an event is created or updated with:

"useDefaultAlerts": false

a subsequent CalendarEvent/get should return false, and the event should not use the calendar’s default alerts.

Actual Behavior

Stalwart accepts the CalendarEvent/set request and reports the object as successfully created/updated, but a subsequent CalendarEvent/get returns:

"useDefaultAlerts": true

The same behavior occurs both when:

  • creating a new event with useDefaultAlerts: false
  • changing an existing event from true to false

Current source appears to treat a missing per-user event preference as true in CalendarEvent/get, while CalendarEvent/set does not persist the false state.

Reproduction Steps

  1. Create a calendar event using CalendarEvent/set with:
{
  "uid": "default-alert-test",
  "calendarIds": {
    "<calendar-id>": true
  },
  "title": "Default alert test",
  "start": "2026-09-30T12:00:00",
  "duration": "PT30M",
  "timeZone": "Pacific/Auckland",
  "useDefaultAlerts": false
}

  1. Confirm that CalendarEvent/set reports the object as successfully created.

  2. Fetch the event using CalendarEvent/get, explicitly requesting useDefaultAlerts.

  3. Observe that Stalwart returns:

"useDefaultAlerts": true

The issue can also be reproduced by creating an event with useDefaultAlerts: true and then updating it with:

{
  "useDefaultAlerts": false
}

The update succeeds, but CalendarEvent/get still returns true.

Relevant Log Output

No error is reported. CalendarEvent/set returns a successful created or updated response and advances the collection state.

Stalwart Version

v0.16.x

Installation Method

Built from source

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

Internal

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

Confirmed as a genuine bug by reading the calendar event set/get code, not just a config issue.

In calendar_event/set.rs, the parsed useDefaultAlerts value is only used locally to decide whether to inline the calendar’s default alarms into the iCalendar data being created (in create_calendar_event), but the boolean is never written back into the event’s per-user EventPreferences.flags (the PREF_USE_DEFAULT_ALERTS bit). There is no code path in set.rs that calls event.preferences_mut(personal_id) to persist the flag.

Meanwhile, calendar_event/get.rs derives the returned useDefaultAlerts value as:

calendar_event.preferences(personal_id).is_none_or(|v| v.flags & PREF_USE_DEFAULT_ALERTS != 0)

Since a preferences record for the account is never created or updated to clear that flag, preferences(personal_id) remains None, and is_none_or falls back to true regardless of what was submitted. This matches exactly the behavior you reported: useDefaultAlerts: false is accepted on create/update but Get always reports true.

This is a legitimate bug in the CalendarEvent set/get implementation, not a documented limitation. A staff/community member will need to patch set.rs to persist the flag into EventPreferences on create and update. I don’t have a fix timeline to share, but your report is accurate and reproducible from the source.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

Fixed in v0.16.22 (yet to be released).