Reading somebody's calendar is easy. Writing back to it is easy. Doing both at once is where the interesting failure lives, and it is the reason many products quietly offer only one direction.
The echo
You create an event. It syncs out to the external calendar. The external calendar reports a change. The sync reads that change, sees an event it does not recognize as its own, and writes it back in. Now there are two, or the same event updates itself in a loop, and the household watches their calendar fill with duplicates in real time.
Every write has to be identifiable later
The fix is that each event carries a record of where it came from, so an incoming change can be recognized as the echo of an outgoing one and dropped. That sounds obvious and is genuinely fiddly, because external providers rewrite identifiers, split recurring series, and report changes that are not changes.
And the same discipline applies to reschedules
Any automatic action — moving a due date after a service is logged, rescheduling a recurring chore — has to be idempotent. If the same trigger fires twice because a message was delivered twice, the second run must be a no-op rather than a second reschedule. Assume at-least-once delivery and design for it, because eventually you will get it.