Changing calendar default alerts does not update CalDAV alarms for existing events using useDefaultAlerts

Issues
1

Issue Description

Calendar defaults appear to be copied into an event’s stored iCalendar when an event with useDefaultAlerts: true is written.

Changing defaultAlertsWithTime/defaultAlertsWithoutTime later updates the calendar preferences, but does not update existing events, so their CalDAV VALARMs can become stale.

Expected Behavior

Events with useDefaultAlerts: true should reflect the calendar’s current default alerts.

Actual Behavior

An event can continue exposing the old materialized default through CalDAV after the calendar default has changed.

Reproduction Steps

  1. Set a calendar default alert for 10 minutes before.
  2. Create an event with useDefaultAlerts: true.
  3. Confirm CalDAV exposes a 10-minute VALARM.
  4. Change the calendar default to 20 minutes before.
  5. Fetch the event again through CalDAV.
  6. Observe that it still exposes the old 10-minute alarm.

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.

on

2

Based on a look at the source, this matches the current behavior: default alerts are materialized into an event’s iCalendar only at creation/update time (see create_calendar_event in calendar_event/set.rs, which copies the calendar’s default_alerts into the event’s VALARM components when useDefaultAlerts is set). Changing defaultAlertsWithTime/defaultAlertsWithoutTime on the calendar (handled in calendar/set.rs) only updates the calendar’s own preference record; there is no code path that re-materializes or refreshes the stored VALARMs on existing events that reference the old default. So the stale-alarm behavior you’re seeing is consistent with how the feature is currently implemented, not a config issue on your end.

This looks like a genuine gap rather than something covered by documented configuration, so I’ll leave this for a human to confirm and address.

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

3

This had been fixed as part of the v1.0.0 refactor and it can’t be backported to v0.16. v1 is expected for late October early November.