Sometimes when we update a recurring Google Calendar event’s recurrence, the API call succeeds, but no update is performed; ie, the event returned by the API call is identical to what it was before except for a change in the etag.
If we first remove the recurrence entirely and then replace it with the updated RRULE it succeeds, but this also removes all of the recurring event instances (and any one-off changes) and replaces all the instances with new ones. It seems to indicate, though, that there wasn’t an issue with the RRULE itself, given the API will happily accept the new RRULE if we delete the old one entirely first.
I couldn’t find any documented reason why the event PUT (or PATCH) APIs would silently fail to update recurrence to a new value, so this feels like either an API bug or a documentation bug. If there is some reason why a valid change to an RRULE should be silently disregarded, that should be documented somewhere. If there’s not a reason for it to behave this way, then there’s something broken with the API for it to do this.
I have of course verified that we can change other fields in the same events, and that we can change the RRULE in other events for the same users. It’s a problem specific to the recurrence field of some events for some users, and once it happens to an event, it continues to happen to that same event forever (unless we delete the recurrence entirely first as I mentioned above).
In the event you are unable to have your inquiry resolved here, please feel free to reach out to the Google Calendar Community: Google Calendar Community
Someone had posted a fairly similar question there a few months ago and just had their thread closed without any help. It was not encouraging. I was unable to find either a similar question nor an answer to this question anywhere else. I’m also trying StackOverflow in the event that perhaps someone there may have seen a problem like this before.
I have discovered the reason this happens, and as is often the case, the answer is that it’s insufficient documentation and poor error handling by Google.
The root cause is someone making an edit to the series at any point and choosing “this and future events” for which events they’d like the change to apply. When this happens, Google creates a new series event with an ID like that of the original recurring event, followed by “_R” followed by the timestamp at which the series was split. So for example, 0mku05shes4kef7fg5gvh2me57 is followed by a new recurring event, 0mku05shes4kef7fg5gvh2me57_R20251015T021500.
Once this happens, the original event will refuse any further attempts at extending the UNTIL value in the RRULE, and unfortunately as outlined in the question, it does so silently: the request gets a 200 response and a valid response, but simply discards the change. It’s somewhat sensible not to change this value, because then events from the original series would begin to encroach upon events from the new series. (What’s not sensible is silent failure: this really should result in a 400 response with a useful error message from the API.)
There is unfortunately no linkage visible via the API between the original recurring event and the replacement recurring event, though at least as long as Google doesn’t change their ID scheme, it’s possible to figure out the original recurring event ID from the new recurring event ID and to work backwards. This linkage must exist on Google’s side, however, because they know to reject the update to UNTIL, and if you cancel the replacement recurring event, it again becomes possible to extend the original recurring event. Also if you cancel the original recurring event, it will cancel both the original and the replacement recurring event (as one would probably expect).
Hopefully this post will be sufficiently searchable that the next time someone runs into this problem, it will save them some time figuring it out.
