Just adding that I'm also seeing this issue. We have an add-on that allows the user to schedule an update overnight. If the script tries to set another trigger, it will be disabled for an unknown reason.

I reported a similar issue here, though in my case I am not creating an additional trigger in another trigger function. Instead I am trying to create onFormSubmit triggers from an HtmlService interface that calls a trigger-builder function using google.script.run in a Forms add-on. Triggers are created as expected (when testing with the add-on installed and enabled), but they do not fire. I have never heard of triggers becoming disabled as the original post in this bug report suggests, but perhaps that is the issue in my case as well.

Hello,

I created 2 triggers with triggerBuilder from appscript as you can see below

function onOpen() {
  if(ScriptApp.getProjectTriggers().length == 0) {
    ScriptApp.newTrigger("openRecord")
      .forSpreadsheet(SpreadsheetApp.getActiveSpreadsheet())
      .onOpen()
      .create();
    ScriptApp.newTrigger("openRecord")
      .timeBased()
      .after(5000)
      .create();
    ScriptApp.newTrigger("changeRecord")
      .forSpreadsheet(SpreadsheetApp.getActiveSpreadsheet())
      .onChange()
      .create();
  }
}

In the middle you can see an time based trigger with option after.

The need that i have is to let a user copy from a template sheet (with appscript code) and when he open the new copied sheet it should create 3 triggers :

• One onOpen
• One onChange
• One timebased after (this one is used to fire a simulate onOpen for the first attempt)

When i copy the sheet with another gmail account, all 3 triggers are never fired. the only one to fire correctly is the simple trigger onOpen that create the three triggers.

Can you help us with this issue.

If i disable v8 the lose the right to create installable trigger as you can see below :

You do not have permission to call ScriptApp.getProjectTriggers. Required permissions: https://www.googleapis.com/auth/script.scriptapp at onOpen(Code:49)

but in the manifest i already added the scope

{
  "timeZone": "Europe/Paris",
  "dependencies": {
  },
  "exceptionLogging": "STACKDRIVER",
  "oauthScopes": ["https://www.googleapis.com/auth/forms", "https://www.googleapis.com/auth/spreadsheets", "https://www.googleapis.com/auth/script.scriptapp"],
  "runtimeVersion": "DEPRECATED_ES5"
}

Hello there!

Is anyone still experiencing this?

That could be the case.

I cannot reproduce this, but this was only reproducible in some accounts when it was first reported. Therefore, can you check if you still experience this behaviour?

I've still got same issue - my script works in sequential executions and each execution if it decides that there is more to do recreates itself with

    var had_Error = false;
    do {
      had_Error = false;
      try {
        ScriptApp.newTrigger("somefuncname").timeBased().after(5).create();
      } catch (e) {
        console.warn("func() has to be retried: " + e);
        had_Error = true;
        Utilities.sleep(2000);
      }
    } while(had_Error == true);

This used to be working fine for months, but got broken somewhere in December-November and at the moment works only in non-V8 mode that is dramatically slower and my solution gets hit by trigger time quota really bad

I experienced a similar problem from a Gmail add-on. This is the issue with the explanation: https://issuetracker.google.com/issues/180020842

I've come across a 100% reproducible case, but this happens only in my workplace Google Workspace account and not when I am executing the script on my private Gmail account.

What steps will reproduce the problem?

1. Create a stand-alone Apps Script project with this script in GitHub
   This is a script framework designed to execute triggered functions based on the user's office hours.
2. Modify the value of CAL_ID_HOLIDAY_JA to the Google Calendar ID of your locale's holiday calendar, e.g., en.japanese#holiday@group.v.calendar.google.com
3. Manually execute initialTrigger

What is the expected output? What do you see instead? If you see error messages, please provide them.

Three triggers, i.e., one for the resetTriggers function and two for createOfficeHourCheckTrigger will be created without an error. The expected output is that all triggers will fire without error, however, the trigger for createOfficeHourCheckTrigger will become disabled at the time of its execution. I have attached the screenshot of the disabled trigger and its Disable reason message: This trigger has been disabled for an unknown reason.

Please provide any additional information below.

As the reporter pointed out, the triggers worked without any problem if I switched the runtime to DEPRECATED_ES5 and made subsequent adjustments to the script as in this GitHub branch

150756612

Speaking of workarounds, you want to have a recurring trigger that you remove after you are done. I talk about it this Medium story, my thoughts on trigger stability are towards the end of the article. https://medium.com/geekculture/bypassing-the-maximum-script-runtime-in-google-apps-script-e510aa9ae6da?source=friends_link&sk=ca2b3c4d2fa429e02ba5f81a94d0c780

Problem

I ran into the same issues:

• Using V8 runtime (in appsscript.json)
• Card-based Add-On
• Trigger created from within card-based add-on always disables after first execution
• Tried to revert to runtime DEPRECATED_ES5 (in appsscript.json), did not work.
• Apparently, card-based add-on needs runtime V8.

Solution

In my testing environment (card-based add-on deployed as "Test deployements"), the following approach of using a web app seems to work for me (disclaimer: I have not yet tested this with a publicly deployed card-based add-on). This is my approach:

STEP 1: Web App Code (simplified version):

function doGet(request) {
  try {
    const trigger = ScriptApp.newTrigger('name_of_function')
        .timeBased()
        .everyHours(1)
        .create();
    return ContentService.createTextOutput(`Trigger created with id ${trigger.getUniqueId()}.`);
  } catch (error) {
    return ContentService.createTextOutput(`Request failed. Error: ${error}.`);
  }
}

Important: My add-on is used by different people, so when I deploy the web app, I set "Execute as" to "User accessing the app" and "Who has access" to "Anyone with google account". This way each user will get their own separate trigger installed (owned by the respective user).

STEP 2: Install the trigger by calling the web app from within the actual Google Workspace Add-On

Instead of executing ScriptApp.newTrigger(fnName)... from within the card-based add-on, I now call the web app url with UrlFetchApp. It is important to send auth token in headers, otherwise the doGet() function of the web app is not executed but instead the google login screen is returned in the response object. Here is the "simplified" code:

const params = {
  method: 'get',
  headers: { Authorization: `Bearer ${ScriptApp.getOAuthToken()}` },
  followRedirects: true,
  muteHttpExceptions: true,
};

// the following URL should be your "Current web app URL"
const url = 'https://script.google.com/macros/s/SOME-LONG-STRING/exec';
const response = UrlFetchApp.fetch(url, params);
console.log('UrlFetchApp response: ', response.getContentText());

Doing it this way ensures that there is no additional interaction for the user. By using UrlFetchApp the trigger can be created from within the card-based Google Workspace Add-on.

Maybe this will work as a workaround for some of the folks in this thread until Google fixes this bug.

Again: I have not yet tested this with a publicly deployed add-on. Will keep you updated on this.

If anyone has experience with using this workaround with a publicly deployed add-on, please comment.

Is anyone at google even working on this problem? Far out it's unbelievable how much time I've spent on this google calendar addin just to be kneecapped at the very end...

As noted above, using the previous version (the Rhino runtime) doesn’t work for the new card based addons, it only works for the old kind of addons.

Hi!

We tried the posted workarounds, but nothing worked for us. When we tried for example to install the trigger by calling the web app from within the actual Google Workspace Add-On, the fetch request returned a 401 response. We tried to send that request after we install the trigger (so sort of a passive way), and we also tried that to fire on user interaction (on a button push dedicated for that fetch request). Both returned 401 without much usable information. Sample response for that scenario:

{ 'Cache-Control': 'private, max-age=0',
  Date: 'Tue, 08 Feb 2022 12:57:19 GMT',
  'X-Content-Type-Options': 'nosniff',
  'Content-Type': 'text/html; charset=UTF-8',
  'WWW-Authenticate': 'Bearer realm="https://accounts.google.com/"',
  'X-XSS-Protection': '1; mode=block',
  Server: 'GSE',
  'alt-svc': 'h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"',
  'Transfer-Encoding': 'chunked',
  Expires: 'Tue, 08 Feb 2022 12:57:19 GMT',
  'X-Frame-Options': 'SAMEORIGIN',
  'Content-Encoding': 'gzip',
  'Content-Security-Policy': 'frame-ancestors \'self\'' }

<HTML>
<HEAD>
<TITLE>Unauthorized</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
<H1>Unauthorized</H1>
<H2>Error 401</H2>
</BODY>
</HTML>

We also tried to trigger an external microservice (calling an endpoint of that service which would call back to our calendar application, with the same style like we did from the internal), but that didn't help either - although the issue might be with our external service

We also tried to use the DEPRECATED_ES5 runtimeVersion or uncheck the Enable Chrome V8 runtime in the project settings, but neither seemed to work. As the previous commented noted, we also tried to get hold of someone in the Google team, to see if this issue is actively under work as it is 2 years old, but Google doesn't seem to care that much.

Could anyone please help or push us into the right direction, what could've gone wrong with our trials to make a workaround of this issue, as it is pretty much makes our integration unusable. Thank you!

Dear ha...@gmail.com: If you've got any other way we can get Google's attention, please, do let me know!

I have even called them up via the developer support, the answer I got was this after the phone call:

Thank you for your patience. I have tried to investigate the possibilities that would be available to me but there is no way I can speed up the process or impose any action on the developer directly. As long as the bug has an owner that means that there is awareness over it. If the engineer will decide that an update is necessary, please rest assured that he will provide that.

As best effort, I will do my best to see if there is any way that I can suggest an update on the thread from the engineer that is working on the bug. If that attempt succeeds, than you will be able to see the comment from the engineer appearing in the thread.

Unfortunately this is the most I can do since I can not influence the processes that have to be taken in the handling of this bug in a direct manner.

If their own support staff cannot promise to find the mysterious "mi...@google.com" person in their internal messaging system, and chat them up with a simple "Hey, this issue is gaining a lot of momentum and hasn't been looked at for over a year" then what else do you suggest I do to get their attention, other than spamming every day this thread so that they receive some internal signal that this is an issue a LOOOOOOT of people are facing and it is clearly on their side? All I am asking is that they provide an acknowledgement of the problem and a confirmation that they're taking this seriously. Please, once more, come forward with the idea on how to get their attention, and I'll do as you say. Be my guest!

I am experiencing the exact same issue. Users who use Google to authenticate against the web app, but do not have some form of access to the script project itself, are unable to install triggers that should be created by a trigger on the server-side.

I logged this again and it has been marked as a duplicate. Two years later it is still a problem and means the Calendar add-on I have listed on the marketplace is hobbled.

Hey hey. Hows everyone doing? Nice little community we've got going around A VITAL FUCKING BUG FROM 2 YEARS AGO JESUS

If you're just joining us, the only fix I've found for this is to downgrade your entire code to the ES5 engine.

Even then, I've just come across a few users that have their 'calendar - changed' trigger disabled for 'an unknown reason'. I'll be making a seperate bug report for it once I've investigated further.

Hey, Google devs, if you're going to axe addons, just put us out of our misery already. This is shit.

Seems like it is time for us to start creating new threads, re-explaining the issue, asking Google not to merge into a thread assigned to a dev who no longer does any dev.

I've been trying to implement the workaround described in #94 today but all I'm getting back is 401 errors.

After doing a bit of digging through the issue tracker it seems Google broke the underlying mechanism it uses without warning based on this reply in a separate thread:

Yes,

It is now not possible to use WebApp as an endpoint. Unfortunately, there is no documentation.

Thanks!

It seems since around mid April 2022 you can no longer call a web app endpoint authorised as a given user by passing the Authorization header containing an OAuth token.

So there is now no way to use installable triggers with the new card based workspace add-ons.

Hi,

To anyone affected by this, can you provide an affected script id?

I have workarounds in place for this in my editor add-on and have disabled my card based add-on altogether but if you are able to look back at past data my script ID is 1rt6HKLYUD5oXzoecSMpEnXv5d3AI40_3Qa8IvcqYQoVi6meWvRIeyP5g.

Thank you for providing the requested information.

Thanks for the info, great news if this is the case.

What does this mean for event based triggers, are they still not working?

I've done some initial testing on my card based add-on and.. they do seem to be working now 🥳

Hello,

A fix has been released. Can you check if this is fixed for you as well?

Regards.

Not able to confirm yet myself, but if it is fixed thank you so much for all the hard work that you put into it.

I know there is a lot of frustration in these issue tracker threads, so it's really appreciated when issues do get fixed!

So good to have this fixed. I have deployed a version of my published add-on with time triggers and it works well. Thank you.

Hi everybody,

I had a slightly different scenario: a webapp that, when executed (doGet), would install a time based trigger.

After researching extensively I found out that there is a way to fix this issue without reverting to DEPRECATED_ES5, and it's buried as last point of https://developers.google.com/apps-script/guides/v8-runtime/migration

"Update access to standalone scripts For standalone scripts running on V8 runtime, you need to provide users at least view access to the script in order for the script's triggers to work properly."

I tried and it worked for me: after changing the sharing settings to "Anyone with the link", the triggers weren't failing anymore.

I'm aware that this is not a solution for every case, as it would expose the code; at the same time, to access such script the users would still need to have the link to the script (don't share it!); also, if you don't have sensitive info hardcoded (like credentials), you could just obfuscate the code.

So you'll have to weigh yourself the trade-offs of this solution, but I hope this helps someone, at least in some cases!