Aug 30, 2021 08:03 AM
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?
Aug 30, 2021 10:16 AM
Are you sure that the holdup is the fetch?
Are you assigning the result of the fetch to a variable? Are you waiting for the promise to resolve elsewhere in the code?
Aug 30, 2021 02:17 PM
My interpretation is that this code should fire and forget about the web service it called. Literally, it should run in about 1.1 seconds every time, but it doesn’t - it runs for however long I instrument the endpoint to run plus about 4 seconds on average.
Aug 30, 2021 02:47 PM
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?
Aug 30, 2021 03:05 PM
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.
Aug 30, 2021 05:30 PM
After a bit more experimenting, I think that the issue is with how Airtable implements fetch in automations. I think it is unrelated to Google or the redirects. We already know that fetch in automations don’t work the same as fetch elsewhere. Maybe this is one more difference.
Aug 31, 2021 02:16 AM
Hi @kuovonne , @Bill.French ,
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.
Aug 31, 2021 07:19 AM
: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.
Aug 31, 2021 07:41 AM
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 !