IssueTracker

Hello,

Thank you for creating this issue.

This behaviour was already reported internally. You can click the star on the top left in this page if you want to keep track of this.

Kind regards.

Do we have any status update on this?

+1 It makes no sense V8 supports async function definition format but there is no real implementation behind that.

https://developers.google.com/apps-script/guides/v8-runtime

The internal discussions so far have borne out our concern that true async operation is something that would confuse many casual Apps Script users. async can be hard to debug and understand, and requires the developer to be familiar async behavior (callbacks) and if I/O calls to dependencies are also async.

These limitations can be worked around by using:

1. var trigger = ScriptApp.newTrigger("myFunction").timeBased().after(30 * 1000).create(); (limited to 90mins execution time per day currently) and use an external data store (such as a Google Sheet) or Script Properties.
2. https://github.com/tanaikech/RunAll (uses fetchAll() in one function to trigger other executions via a doGet() to the same or another funciton)

These methods allow developers who understand async ops (and state management) to intentionally gain access to that powerful functionality, without causing a majority of users to encounter behavior that they think is incorrect. That negative experience would likely drive users away and otherwise harm adoption and usage of Apps Script.

Having said that, we should call this out in our public docs to avoid people spending time refactoring code as mentioned in #comment7. I will inform the proper team, expect an update in the next month.

How are these approaches less confusing? This is mind boggling. Document scripting is supposed to be easy but almost every weird quirk of Apps Script makes things harder than "normal" programming.

BTW Async debugging is certainly possible and easy as shown in Chrome Dev Tools. Perhaps improving tooling rather than restricting features would be more beneficial?

Also even if restricting features ends up the solution you must do better job. I don't think improving documentation is enough - show warnings/errors in editor for unsupported code.

The assumption that the majority of users would be confused by async working like async, sounds extremely condescending...

Maybe google team could explain a little further their thoughts regarding this.

So, because you think that async is too difficult for casual Apps Script users, you have decided to actively:

1. Gimp the language.
2. Divert from the Ecmascript Language Specification.
3. Split the eco-system and make trouble-shooting harder for those who expect Javascript features to work like they are supposed to.
4. Ensure that many Google Workspace Marketplace apps are slower than necessary and that both developers and end-users of them have a less than stellar experience.

... Please reconsider.

We certainly are not slighting developers implying that people wouldn't understand. We use Apps Script extensively within Google. Apps Script has not had concurrency since the inception. The addition of keywords to conform to the language spec didn't change the behavior of Apps Script as it was implemented/used. As such this is a Feature Request to implement true async in Apps Script.

Perhaps a warning on the keyword usage is an option.

Developers "in the know" can already get around this using timers and google.script.run, and that is our suggested workaround (as it already was, like in #comment19) until we can prioritize work regarding warnings or manifest flags.

At this point I do not have an estimate of when that work could commence.

async/await do function as expected, the issue is that the underlying tasks in Apps Script are synchronous/blocking and thus the task queue is still synchronous.

someone proposed this in this thread. has this been taken into consideration?

Perhaps a warning on the keyword usage is an option.

Yes, please. This would have helped avoided the issue over a year ago where I wasted a bunch of time trying to use async to you know... make asynchronous calls. At least I with a warning, I would have found out the most straightforward approach won't work.

It's more nuanced, however, as WebAssembly.instantiate does in fact run asynchronously and the async/await syntax is valid, https://justin.poehnelt.com/posts/apps-script-async-await/#webassembly-in-apps-script.

interesting thank you