ERROR : Exceeded maximum execution time

[theophanemayaud]

Steps to reproduce

Maybe I set too many reminders : anticipateDays: [0, 1, 7], and I have a lot of contacts with birthdays. But I don't know for sure what is causing this.

Expected behavior

The script should not run longer than the max time allowed by google app scripts !

Current behavior

On some days when an email reminder is sent to me, it is also followed by an email from apps-scripts-notifications@google.com saying basically :

Start	Function	Error Message	Trigger	End
3/16/19 10:19 AM	normal	Exceeded maximum execution time	time-based	3/16/19 10:26 AM

Context

  version: '4.1.0',
  repoName: 'GioBonvi/GoogleContactsEventsNotifier',
  gitHubBranch: 'development' 

The script doesn't use google +, and the config code will be below.

Extended description

The exact mail from google app scripts is :

---

Subject : Summary of failures for Google Apps Script: Contact birthdays custom mail notifications
Your script, Contact birthdays custom mail notifications, has recently failed to finish successfully. A summary of the failure(s) is shown below. To configure the triggers for this script, or change your setting for receiving future failure notifications, click here.

Start	Function	Error Message	Trigger	End
3/16/19 10:19 AM	normal	Exceeded maximum execution time	time-based	3/16/19 10:26 AM

Sincerely, Google Apps Script Need help? Visit the Google Apps Script documentation. Please do not reply to this message. (c) 2019 Google

---

Today, the email I received before the notice of failure was a notice for one contact, which had five email addresses and three phone numbers.

I don't exactly know what the problem is since I do receive a notification email for the birthdays, before I get the notification that the script took too long to run. I will leave the code of my setup below.

Possible solution

I have read somewhere that the max run time for google app scripts is 6 minutes, and the only solution is having a script run partially while keeping track of time, then stop before 6 minutes saving the current state somewhere (ex in a spreadsheet), then start again reading the last state etc...

My config code

var settings = {
  user: {
    googleEmail: 'not_disclosed_here@gmail.com',
    notificationEmail: 'not_disclosed_here@gmail.com',
    eventSource: 'CONTACTS_ONLY',
    emailSenderName: 'Contacts Events Notifications',
    lang: 'en',
    accessGooglePlus: false
  },
  notifications: {
    hour: 10,
    timeZone: 'Europe/Paris',
    anticipateDays: [0, 1, 7],
    eventTypes: {
      BIRTHDAY: true,
      ANNIVERSARY: false,
      CUSTOM: false
    },
    maxEmailsCount: -1,
    maxPhonesCount: -1,
    indentSize: 4,
    compactGrouping: true
  },
  debug: {
    log: {
      filterLevel: 'INFO',
      sendTrigger: 'ERROR'
    },
    testDate: new Date('2017/08/01 06:00:00')
  },
  developer: {
    version: '4.1.0',
    repoName: 'GioBonvi/GoogleContactsEventsNotifier',
    gitHubBranch: 'development'
  }
};

[GioBonvi]

Hello @CoVoCre,
thanks for bringing this up: you correctly identified the problem and the possible solution, however i think it was already discussed somewhere and it was decided not to implement it because it would have been difficult to implement such a feature cleanly (especially given the not so clean already existing code base); on a more personal level it would require more time than I am able to dedicate to this at the moment.

If anyone is willing to give it a try it would be great: I'll leave this issue open as a reminder.

[rowanthorpe]

Just a quick thought/question about this (unfortunately all I have time for): how hard would it be to keep a non-transitory object (spreadsheet, as suggested?) and an associated non-transitory transaction-log where the additions to the object are built in-memory and atomically appended to the object at the same time as logging atomically to the transaction-log (including when processing yields no addition to the object, which is still progress needing tracking). The idea would be that the script could be killed at any time (at 6 minutes as mentioned, or perhaps any other unexpected time/reason) and as far as the engine can ensure we should never have a corrupted object or log, making the the task easily continuable (just rerun on restart until the transaction log indicates completed status, then format output from the object to fire off) without needing to keep track of time and preempt any timeouts. This is a bit like the -C - option of curl. If do-able this would be cool, but I suspect it would be mind-numbingly time-consuming though.