GET/POST using Fetch() from Script Automations!

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?

Good questions…

No.

No.

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.

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.

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.

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.

Best regards,

olπ

: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…

1. 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.

2. Insulating webhook calls in script automation by using a proxy is also not helpful unless you transform the webhook itself into a non-blocking architecture that can respond quickly and then perform the processes after the response. This sounds easy, but it is not - in fact, it’s impossible - return() after all, is terminal. There’s no such thing as return(), but do all of these things after the fact. If there is such a capability in javascript, I’m all ears.

3. Designing a proxy to overcome this javascript implementation shortfall requires that you cache-forward whatever long processing actions that need to be performed as well as any arguments passed to the webhook; yet again, additional complexity.

4. 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.

Opinion…

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 !

Best regards,

olπ