Hi @pim

How many tasks is it typically holding when you make a change?

They feature that is holding them is called "flood protection" - it kicks in if more than 100 tasks try to trigger at once.

You can have the threshold raised, up to about 2,000 I think. So long as you've got filters in your zaps to stop wasted tasks, this might be your easiest fix. Just write to support and they'll handle it for you.

Hi @pim! This is a bit of tricky one - the Zapier Google Calendar integration doesn't handle recurring events very well because (as you've found) a recurring event essentially repeats for infinity!

There isn't a way to safely update a recurring event using Zapier, but you can add a filter to your Zap so that you can update an event without it triggering a deluge of tasks.

If an event is a recurring event, it will pass a field called 'recurringeventID', that you don't get with non-recurring events.

That's the field that you need to use to stop your Zap from triggering when a recurring event is updated:

1. Add a filter step into the Zap.
2. Set the filter to look at the field 'RecurringeventID'
3. Set the condition to 'Does not Exist'

The tricky part of adding this step is that the field isn't passed by events that aren't recurring, so you'll need a sample in your Zap that is from a recurring event.

Secondly, if you add this filter then your Zap wont continue if you update a recurring event, meaning that you will manually need to sync that with your other calendar.

​I hope that helps, please let me know if you have any questions!

@pim and @Danvers I had an additional thought about this issue, and wondered if instead of running a filter you switched it to a path, and path A handles your non-reocurring events, whereas Path B handles your recurring events.

In Path B I would start with the following steps:

• Storage, look for the value of recurringeventID inside a Key, for example modified-events
• Filter - if the value was not found, continue, if it was found then stop the zap
• (do your changes in the planning tool)
• Storage - push value to Key, pushing it into the same key you looked for above.

Two caveats:

1. Storage as a limit to the number of characters (bytes) stored in a key and using the above method I have hit it pretty quickly for some clients.
2. This would prevent changes to any reoccurring event from getting to your planning tool if the event had already been changed once.

The solution I used for my client to solve those two caveats was:

• Have a zap that fires off at 12:01am and creates a new Key in storage basically modified-events-(date) where the (date) is replaced with today's date.
• then in the Path B of the above step use {{zap_meta_human_now}} to get today's date (might need a formatter step to get it in the right format) and then use that in the Key name modified-events-(date) in both storage steps.

The caveat on that is if a recurring event is changed twice in the same day it will only "sync" the first change.

All that being said you'd still want to request the increase @AndrewJDavison_Luhhu suggested, because each event will need to run through this path and I assume you'll still hit the flood protection issue.

Hi there, I recently had a Zap go awry because it seems Google has gotten rid of the Recurring Event ID? Does anyone know how to fix this again? I can’t use Google Calendar zaps with Zapier if I can’t get it filter out recurring events because recurring events use like 1400 zaps at a time.