The create and update paths handle useDefaultAlerts differently.
On create, CalendarEvent/set uses the result of update_calendar_event() to materialize calendar defaults as VALARMs.
On update, that return value is discarded, so changing useDefaultAlerts does not appear to rebuild the stored alarms.
Expected Behavior
Changing useDefaultAlerts should update the event’s effective iCalendar/CalDAV alarm set accordingly.
Actual Behavior
The stored VALARMs can remain inconsistent with the new useDefaultAlerts value.
Reproduction Steps
Create a calendar with a 10-minute default alert.
Create an event with useDefaultAlerts: false and a 30-minute event alert.
Change only useDefaultAlerts to true.
Confirm JMAP reports useDefaultAlerts: true.
Fetch through CalDAV.
Observe that the alarm set was not rebuilt to use the calendar default.
The reverse (true → false) may similarly leave a previously materialized default alarm behind.
Relevant Log Output
N/A
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.
This confirms the report accurately: the update path discards use_default_alerts from update_calendar_event(), unlike the create path which uses it to materialize default VALARMs from the calendar. I have enough to confirm the bug is real and reply.
This confirms the report: the create path (create_calendar_event, line ~779) extends ical.components with default_alerts(...) when use_default_alerts is true, but in the update path (update_calendar_event call around line 297), the returned use_default_alerts value is discarded (if let Err(err) = ...), so no equivalent rebuild of alarms happens on update.
This is a genuine bug report with clear repro steps and no existing docs would cover this behavior; I’ll confirm to the user this looks like a valid, well-diagnosed bug.
Your analysis is correct and matches what’s in the source. In create_calendar_event, the use_default_alerts value returned by update_calendar_event() is captured and used to append the calendar’s default VALARMs to the new iCalendar. In the update path (CalendarEvent/set update handler), the call to update_calendar_event() only checks for Err, discarding the Ok(use_default_alerts) value, so the equivalent alarm-rebuild step never runs when useDefaultAlerts changes on an existing event.
This is a real discrepancy between the create and update code paths in crates/jmap/src/calendar_event/set.rs, not an intentional behavior documented anywhere. A staff member will need to confirm the fix (rebuilding alarms in the update path the same way it’s done on create).
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.