The issue with calendar alarms

[Bron Gondwana]

Calendar alarms and replication are a real problem for the
following reason:
1) calalarmd needs to only run on the master, not the replica -
   otherwise the alarm will fire on both, and the alarmd on the replica
   will write annotations, causing split brain issues.
2) the caldav_alarms.sqlite3 database on the replica needs to have all
   the nextalarm values in sync with the master, so if there's a
   failover event, the calalarmd on the ex-replica knows which records
   are interesting without having to parse every single mailbox!
3) replication and annotations is a disaster - the record gets written
   first, and the annotations later.
So we solve this as follows:

a) if record.silent is set, we don't write the caldav_alarms.sqlite3
   event line for the record immediately.
b) AFTER we have applied both the record and any annotations for the
   record in sync_support.c, we call caldav_alarm_touch_record(), which
   can then read the annotation to see when the nextalarm should be.
The problem is this: if there's already a nextalarm value, and we change
a record to have an earlier alarm for whatever reason, the alarm
annotation just gets copied by dav_store_resource to the new record, and
hence there's already a nextalarm in the future.  This OVERWRITES the
earlier alarm value created by caldav_alarm_new_record().
The fix is this: instead of blindly overwriting,
caldav_alarm_touch_record needs to have two modes: sync mode and non-
sync mode.
In sync mode, it's a replica - so it just does what it does now -
blindly writes the value from the annotation.
In non-sync mode, it instead always reads the record (plus any per-user
overrides) and finds the time that it next needs to be checked.
Easy-peasy :)  I might even just call it two different things to make it
extra clear what's going on!
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong at fastmailteam.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20171228/23909931/attachment.html>