Skip to content
Advertisement

Google Calendar API: Deleting a Event does not delete an Event Id

First: I create a new event:

event = {
        "id": "tph13",
        "start": {
            "dateTime": convert_to_RFC_datetime(2021,5,10,8,15),
            "timeZone": "Europe/Zurich"
        },
        "end": {
            "dateTime": convert_to_RFC_datetime(2021,5,10,12,00),
            "timeZone": "Europe/Zurich"
        },
        "summary": "TEST_EVENT"
      
    }
   
    event = service.events().insert(calendarId='primary', body=event).execute()

This successfully creates an event in Google Calendar!

Then: I delete the event again:

service.events().delete(calendarId='primary', eventId='tph13').execute()

which successfully deletes the event (at least I don’t see it anymore).

Then: I re-create the same event:

event = {
        "id": "tph13",
        "start": {
            "dateTime": convert_to_RFC_datetime(2021,5,10,8,15),
            "timeZone": "Europe/Zurich"
        },
        "end": {
            "dateTime": convert_to_RFC_datetime(2021,5,10,12,00),
            "timeZone": "Europe/Zurich"
        },
        "summary": "TEST_EVENT"
      
    }
   
    event = service.events().insert(calendarId='primary', body=event).execute()

…but then I get this error:

‘The requested identifier already exists.’

What am I doing wrong?

(For those interested)

def convert_to_RFC_datetime(year=1900, month=1, day=1, hour=0, minute=0):
    dt = datetime.datetime(year, month, day, hour, minute, 0).isoformat() + 'Z'
    return dt

Advertisement

Answer

It is either a propagation issue, or those IDs can never be used again.

From the documentation:

Due to the globally distributed nature of the system, we cannot guarantee that ID collisions will be detected at event creation time.

https://developers.google.com/calendar/v3/reference/events/insert

Though this doesn’t address your exact question, it points to an important issue, that updates take time to propagate.

While there is some advantage to not allowing a previously deleted ID to be created (outlined below), it is possible that eventually these ID’s become available again. In the event of a real ID deletion, it will probably take a few days to propagate through the system. That is assuming that they are deleted from the system at all. In all likelihood, the ID’s will linger for a long time to come.

Why would the IDs want to be kept?

An old ID may be pointed to from one or more other resources. If an app relied on a particular event to gather some information and then found that the ID had totally different information it would be a bit strange. Better for the other resource to find out that the event has been deleted, than to find a totally different event.

In fact, when you make a GET request on a deleted event it will actually return the event with one important field:

"status": "cancelled",

Which makes sense because maybe lots of people have added a reminder in their calendar for this event ID, and if the API allowed you to totally change recently deleted events, then people might start getting reminders for random events.

The fact that it shows up as “cancelled” suggests that the IDs may in fact never be deleted, or at least kept for long enough for the problem above never to be an issue.

Changing an event

If you want to keep the same ID, but want to update the event completely, then you will need to use either the update or patch endpoints.

Reference

User contributions licensed under: CC BY-SA
3 People found this is helpful
Advertisement