You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pull request #164 introduced a new feature/bugfix where the mail merge process (SEND EMAILS and CREATE DRAFTS) that took longer than the execution time limit of postProcessMailMerge, i.e., the apps script's 6-min limit, is handed over to another hourly triggered postProcessMailMerge to work around the Exceeded maximum execution time error.
It would have been more than convenient for users if this second trigger could be executed at a more frequent interval than an hour, but there is an undocumented limitation that recursive time-based triggers created by add-ons must be set at an interval of at least one hour, else it would throw an exception with the following message:
Exception: The recurrence interval for an Add-on trigger must be at least one hour.
To comply with this limitation while maintaining the user experience of the add-on at a certain level, I've broken down the post-process into two steps in the said PR. The first postProcessMailMerge will be triggered on ClockTriggerBuilder.after(milliseconds):
whereas the subsequent postProcessMailMerge, whose time-based trigger will be set when the first round of execution is expected to take longer than the 6-min limit, will be set by ClockTriggerBuilder.everyHours(1) (where 1 is the smallest acceptable number)
While I believe this is the best possible solution currently available, I understand this 1-hour interval will be frustrating for users who are not aware of this process, as it will keep them waiting throughout the recursive hourly executions. To properly inform the user, I would like to add the estimated remaining time to the MESSAGE.<userLocale>.continuingPostProcess.
The text was updated successfully, but these errors were encountered:
Pull request #164 introduced a new feature/bugfix where the mail merge process (
SEND EMAILS
andCREATE DRAFTS
) that took longer than the execution time limit ofpostProcessMailMerge
, i.e., the apps script's 6-min limit, is handed over to another hourly triggeredpostProcessMailMerge
to work around theExceeded maximum execution time
error.It would have been more than convenient for users if this second trigger could be executed at a more frequent interval than an hour, but there is an undocumented limitation that recursive time-based triggers created by add-ons must be set at an interval of at least one hour, else it would throw an exception with the following message:
To comply with this limitation while maintaining the user experience of the add-on at a certain level, I've broken down the post-process into two steps in the said PR. The first
postProcessMailMerge
will be triggered onClockTriggerBuilder.after(milliseconds)
:whereas the subsequent
postProcessMailMerge
, whose time-based trigger will be set when the first round of execution is expected to take longer than the 6-min limit, will be set byClockTriggerBuilder.everyHours(1)
(where 1 is the smallest acceptable number)While I believe this is the best possible solution currently available, I understand this 1-hour interval will be frustrating for users who are not aware of this process, as it will keep them waiting throughout the recursive hourly executions. To properly inform the user, I would like to add the estimated remaining time to the
MESSAGE.<userLocale>.continuingPostProcess
.The text was updated successfully, but these errors were encountered: