GAS-ICS-Sync
GAS-ICS-Sync copied to clipboard
derekantrican
Failure to get web calendar results in all calendar entries being deleted
- Description of the problem When the Outlook calendar cannot be located, all calendar events are deleted
- Log outputs The last two syncs have logs as follows:- FIRST LOG Apr 21, 2020, 5:24:40 PM Info Exception: Request failed for https://outlook.office365.com returned code 403 Apr 21, 2020, 5:24:40 PM Info Syncing 0 calendars to Work Calendar (LIVE) Apr 21, 2020, 5:24:41 PM Info Working on calendar: [masked]@group.calendar.google.com Apr 21, 2020, 5:24:43 PM Info Fetched 241 existing events from Work Calendar (LIVE) Apr 21, 2020, 5:24:43 PM Info Parsed 0 events from ical sources Apr 21, 2020, 5:24:43 PM Info Processing 0 events Apr 21, 2020, 5:24:43 PM Info Done processing events Apr 21, 2020, 5:24:43 PM Info Checking 241 events for removal SECOND LOG Apr 21, 2020, 5:38:33 PM Info Syncing 1 calendars to Work Calendar (LIVE) Apr 21, 2020, 5:38:34 PM Info Working on calendar: [masked]@group.calendar.google.com Apr 21, 2020, 5:38:34 PM Info Fetched 0 existing events from Work Calendar (LIVE) Apr 21, 2020, 5:38:34 PM Info Parsed 244 events from ical sources Apr 21, 2020, 5:38:34 PM Info Processing 244 events Apr 21, 2020, 5:38:34 PM Info Timezone GMT Standard Time unsupported! Apr 21, 2020, 5:38:34 PM Info Using Timezone Europe/London!
I only noticed this because I have emails sent when new items added, and I got 244 emails!
Presume there is scope for failing the sync completely if a 403 error as above is returned?
In the grand scheme of things, not an issue as it replaced all the entries the next time around, but presumably it would be an improvement if dealing with a 403 scenario could be coded for?
We did add some exponential backoff (with ultimately throwing an exception if all requests fail) in Helpers.gs. I don't think it's published in a release yet. Could you try implementing this version of fetchSourceCalendars on your side?
In addition: We could probably stop the run at "Syncing 0 calendars to XYZ" if the total number is 0, however this will not work if multiple source calendars are merged into one target calendar and only some of them are not reachable. At the stage "Checking XYZ events for removal" we do not have information about the target calendar an event came from, therefore we can not distinguish deleted events from events that are from a (temporarily) non reachable calendar. We might be able to change that though if the backoff does not solve the issue.
We did add some exponential backoff (with ultimately throwing an exception if all requests fail) in Helpers.gs. I don't think it's published in a release yet. Could you try implementing this version of
fetchSourceCalendarson your side?
Done that now, probably not feasible to confirm it works but I'll report back if there are any issues.
I've been using this script to synchronise ICS feeds from various hotel booking sites (stayz etc). Just today, Stayz was unreachable (giving a 500 error), which resulted in all Stayz bookings being deleted from the Google calendar.
Perhaps the HTTP status of the ICS feeds could be checked prior to syncing... Would that be a workable solution? Other than this, the script has been working great, thanks.
As already mentioned above we do not track which calendar each event came from, therefore the only option (in a multiple source calendars scenario) would be to completely skip the sync if one calendar is unavailable.
@yellowbarchetta as the one who submitted this issue - do you know how often you were seeing this happen?
Maybe a possible solution would be to just "early exit" that script iteration if any calendars failed the fetch?
Closing this issue for cleanup because #343 seems to be the same issue, but also offers a fix.
