CalendarEvent in CalendarApp... Manual Delete = Still Accessible Through Apps Script?

I have several hundred events on the calendar, all created by Apps Script. I store their IDs in ScriptDB, and have a UI to manage them.

When I delete events manually (through the Google Calendar interface) off of my calendar, they disappear into oblivion, or so I thought. As it turns out, when I load my UI that manages them and I go and try to retrieve the event by:

calendar.getEventSeriesById(eventID),

I can access the events normally as if the event were still on the calendar. The only thing that I can't seem to do, is delete the event. This honestly doesn't make any sense to me, but I'll give my two cents to see if you guys can come up with a reason as to why this might be happening. Here's the run-down of my use case:

1. Create an event through GAS (not manually).
   • Event is now on the calendar, event ID is stored in ScriptDB
2. Load UI - now we can change the date, start time, end time, location, description, etc. of the event, or we can delete it
   • No problems here, everything functions normally and as expected, even when the event is marked for deletion
3. Someone comes along and sees an event on the calendar and says Oh, let's just go ahead and delete that shall we?
   • This is where problems come in, because it's impossible (I'm almost certain) to detect that an event was deleted manually and subsequently set the eventID in ScriptDB to null.

4. Some time later... load up the UI... woah, getting event tags for a deleted event still works? What?

   [13-12-18 16:48:17:941 EST] This is an event that was manually deleted: CalendarEventSeries
   [13-12-18 16:48:17:943 EST] This is the location of the manually-deleted event: C/A
   

5. So now we can access the event, can we make any changes? Spoiler: the answer is 'yes':

   • If I change the date, start time, end time, or location:

I get the following in my Logger (some important messages):

[13-12-18 19:34:12:208 EST] EVENT DATE/TIME CHANGED?: true
[13-12-18 19:34:12:534 EST] Manual change was made to the calendar event. Getting event by ID now...
[13-12-18 19:34:12:980 EST] Event to update (by ID): CalendarEventSeries

• This event was deleted, but apparently we can still make changes to it...

---

So I tried to catch the situation where the calendar event was deleted, but since after fetching by ID (or time interval for that matter), the return is a CalendarEventSeries when in actuality, the expected result is null or 0 or some other falsey-value.

Because I know that I'm the person who deleted the event, I thought oh well, I'll just mark it for deletion in my UI! Guess what: fail: - I tried to call calEvent.deleteEventSeries();, but I received the following error:

So: My only option was to surround the calEvent.deleteEventSeries(); with a try-catch-finally block, which I suppose is a good enough solution. However, I am wondering why manually deleting off of the calendar still allows us access through GAS? The reverse holds to expectations: if I delete an event through GAS, it does actually delete it from the calendar. But deleting from the calendar manually does not remove access to the event by Apps Script.

Finally the question(s): Is this really the intended behavior of CalendarApp and Apps Script? Or is this unexpected or undefined behavior? Are there any workarounds other than surrounding deleteEventSeries() in a try-catch block?

EDIT: According to the original issue on the issue tracker, even if you delete the event through Apps Script, then try and access it using the same iCalId, it still returns the event. So I guess it's not just manual deletion, it's deleting in general. I didn't notice this because when I delete the event, I erase the ID from ScriptDb. Something to look out for!

Bad news, Chris. This has been a known issue for a long time. Issue 2480 was triaged and replicated in an internal bug report by the GAS team 9 months ago.

You've got far more details in your question that what appears in the issue - you should add a note to the issue pointing here!