Cannot read properties of null (reading 'length')

[Lonestarjeepin]

The problem

Edit: After the Outlook 500 issue was resolved and based on some further troubleshooting, I don't think this was related after all so I am removing links to the other issues:

I have been getting these errors intermittently (3-5 times per day), but I couldn't really track them down until now (I also realized the email comes out as GMT, not local time... duh). The callWithBackoff function seems to be working correctly, but the error comes after the code continues (on row 190 in Helpers where it's trying to evaluate calendarEvents.length).

I'm hoping this image embed works:

Nothing secret here... it's a public calendar (GO FROGS!)

I also caught another of my calendars doing it, but this time it executed correctly in the script right before and right after this execution.

Version of GAS-ICS-Sync

6.0 (Settings-v2)

Additional information & file uploads

No response

[dillonator]

I am seeing the same 500 errors with an Outlook O365 sourced calendar. It removed all the calendar entries due to this. Seems to have started on Aug. 14 for me. I have since updated all elements of the scripts to the newest version (been working since 2023!), but still seeing the same 500 errors.

Aug 14, 2025, 9:08:16 PM Info Error: Encountered HTTP error 500 when accessing https://outlook.office365.com/owa/calendar/[removed]/reachcalendar.ics
Aug 14, 2025, 9:08:16 PM Info Syncing 0 calendars to 'test'
Aug 14, 2025, 9:08:16 PM Info Working on calendar: [removed]@group.calendar.google.com
Aug 14, 2025, 9:08:17 PM Info Fetched 84 existing events from 'test'
Aug 14, 2025, 9:08:17 PM Info Parsed 0 events from ical sources
Aug 14, 2025, 9:08:17 PM Info Processing 0 events
Aug 14, 2025, 9:08:17 PM Info Done processing events
Aug 14, 2025, 9:08:17 PM Info Checking 84 events for removal

[gtfuhr]

I'm experiencing the same issue with an Office 365 calendar.

2:11:39 PM Info Error: Encountered HTTP error 500 when accessing https://outlook.office365.com/owa/calendar/[Removed]/calendar.ics
2:11:39 PM Info Syncing 0 calendars to [Removed]
2:11:40 PM Info Working on calendar: [Removed]@group.calendar.google.com
2:11:40 PM Info Fetched 0 existing events from [Removed]
2:11:40 PM Info Parsed 0 events from ical sources
2:11:40 PM Info Processing 0 events
2:11:40 PM Info Done processing events
2:11:40 PM Info Checking 0 events for removal
2:11:40 PM Info Done checking events for removal
2:11:40 PM Info Processing 0 Recurrence Instances!
2:11:40 PM Info Sync finished!

[yermulnik]

It is probably worth of using one single issue for this: #494

[jonas0b1011001]

@Lonestarjeepin i guess this should be enough to fix the issue. Add to

GAS-ICS-Sync/Main.gs

Lines 78 to 79 in 0ef94d3

	var response = getSourceCalendarEvents();
	getTargetCalendarEvents();

var response = getSourceCalendarEvents();
if (!response){
  Logger.log(`Failed to retrieve calendar data.`);
  continue;
}

[Lonestarjeepin]

@jonas0b1011001 ,I think I was seeing it wrong and got mixed up with the Outlook issue happening at the same time. I rewrote the issue description above. The log says "Fetched 12 events from XYZ target calendar", but then randomly fails on calendarEvents.length on the next line which doesn't make sense to me since it just printed the length to the log.

[jonas0b1011001]

The "Fetched x events" is the log output from the target calendar, not the source.

What's happening:
getSourceCalendarEvents(); will return null if it fails
getTargetCalendarEvents(); get's the events from the google calendar and prints "Fetched x events..."
vevents = parseSourceCalendarEvents(response); will try to parse null and throws an uncaught exception that causes the crash

-> We have to check if getSourceCalendarEvents() actually returned something before calling parseSourceCalendarEvents(response);

[Lonestarjeepin]

That makes more sense. I put this in place for now and will monitor to see if it resolves the failures. I can't recreate the failures on demand so I'll check back in a week or two.

  if (!response) { //First check to make sure there was a response before parsing
    Logger.log(`[ERROR] Failed to fetch calendar data for '${calendarConfig.sourceCalendarName}' from the URL. Skipping this calendar sync.`);
  continue; // This command skips the rest of the loop for this calendar and moves to the next one.
  }

[Lonestarjeepin]

I just happened to catch this happen in real-time as I was adding a new sourceCal to my script. This code addition worked exactly as expected. The script skipped the individual calendar, completed all others, and showed overall Status as Failed. However, it feels like the script did exaclty what we hoped it would do. Is there some other status or way to handle that failure so it shows completed but a user could still see that an error was handled (without digging through the logs)? I feel like we had a similar conversation with target calendar failures too. It's almost like we need a way to track contiguous failures across multiple executions and notify the user of that persistent problem and not worry so much about the one-off issues that pop up and get resolved on the next execution. Maybe a PropertiesService variable we could increment?