Okay, SUPER SIMPLE, SUPER DUMB question - how do you create an HTTPs GET in a script automation that doesn’t wait for a response?
More background -
Is it possible that Airtable’s implementation of fetch() is simply unable to act as a non-blocking webhook caller?
Hum. I just started working with Google Apps Scripts and I wonder if the redirects are messing things up? I played around with changing a few things (adding and removing awaits, assigning the result to a variable or not, various try/catches, muting exceptions, etc) and I get different results. Sometimes the script errors out without ending up in the catch. Sometimes the script ends up in the catch and then doesn’t fail.
I suspect that this is some weird combination of Airtable and Google. Have you tried contacting Airtable support?
That was my first assessment as well, but at its core, lacking await, the process should not wait at all. After all, this is a non-blocking script environment, right? So why is it blocking?
A also tested many approaches including a POST - same result - whether awaiting or not - the time always seems to to suggest it is indeed waiting. And that is the rub - what if you wanted to simply begin a long-running process? Given this behavior it is apparently impossible to do.
I read you between the croissant and the coffee (I am a nightShifter).
The first thing that comes to my mind: instead of fetching a GAS endPoint, try the same experience by fetching a nodeJs endpoint?
I don’t currently have some nodeJS endPoint on hand but I have the suspicion that if I activated one locally (in my new M1 MBP), it could also do the job for a “concurrent” attempt, not involving GAS ?
You make me want to try it but my current project’s dueDate of 15/09 oppresses me a bit to finish my current project first.
I push your case to my stack rather than closing this page.
:slightly_smiling_face: That was the first thing I tried; save yourself the trouble by focussing on another croissant - it won’t work.
Ding! Ding! Ding! You are absolutely correct and I’ve verified this by removing Google web services from the tests.
The underlying facts…
Airtable’s implementation of fetch() is apparently synchronous (blocking) by design and there is no option or configuration approach to make it non-blocking. There is also no way to tune script automation timeouts - 30 seconds is a hard number and not unreasonable, of course.
This challenge is unrelated to web services hosted through Google Apps Script; I verified all of these tests with a vanilla NodeJS platform as well.
I was able to solve this with a workaround which I’ve shared here, the vast majority of which would not be necessary if Airtable would simply support a non-blocking fetch.
The world of loosely-coupled services is a topography of messaging. We need to send a variety of messages independent of actions that such messages may trigger. Lacking a dynamic ability to use fetch() in a messaging capacity is a significant constraint and especially so when response timeouts are reconfigurable. Ideally, Airtable’s scripting environments would support the integration of MQTT and other real-time messaging protocols, an idea I have been pushing for (with Airtable) since 2018. Real-time messaging platforms can eliminate APIs altogether while accelerating processes.
I should have guessed you would already have tried Node.js way :winking_face:
I have the Airtable Custom App SDK upon Node.js installed on my desktop but not yet in my brand new macBook M1 otherwise I would have jumped on the case holding the croissant with one hand and the keyboard with the other :winking_face:
(No third hand for the coffee anyway !)
Thanks @Bill.French and @kuovonne for this thorough analysis : I hope it will reach the airtable DEV Coordination !