Help

Re: My VERY VERY Simple script is throwing intermittent error

1321 0
cancel
Showing results for 
Search instead for 
Did you mean: 
Email_Launchese
4 - Data Explorer
4 - Data Explorer

My very simple script (in an automation) to trigger a webhook containing record ID is failing intermittently. I do not know the cause. The error is “Script exceeded execution time limit of 30 seconds”.

Such a simple script shouldn’t ideally throw an error. Can anyone suggest a way forward?

V

2021-06-30 21_22_56-(TEST) Launchese v 2.0_ Contact US - Airtable
2021-06-30 21_24_34-(TEST) Launchese v 2.0_ Contact US - Airtable
2021-06-30 21_27_51-(TEST) Launchese v 2.0_ Contact US - Airtable
2021-06-30 21_28_15-(TEST) Launchese v 2.0_ Contact US - Airtable
2021-06-30 21_28_22-

3 Replies 3

In Integromat, go into your scenario settings and enable “auto commit”. That will send the webhook response back to Airtable immediately, instead of waiting for your entire scenario to finish executing before sending the webhook response.

You could also try removing the await keyword from your script, as long as you don’t have further actions that need you to await.

Oh my, I can’t remember the last time I went “hmm, sounds like a perfect problem for the try…catch statement,” but that’s literally what this is. You have three lines of code in total, so you don’t have to worry about the performance implications of that pattern, contrary to roughly one in one other user that might be considering adding yet another memory hog to their code base at any given time.

So, if you still haven’t figured this out seeing how my response is a day late, I’d suggesting reading this, applying it to your use case, and getting a nice, clean log of the error. Your next steps should become clearer afterward, assuming your terrible luck doesn’t continue.

You leaving an await on that last line is an example of making your own luck, though. Get rid of that, like Kuovonne already pointed out and was previously implied ; it just does not make sense to write that syntax in that context, despite no errors being thrown at you. In fact, the issue might be way more convoluted than you’d suspect those three lines of code could cause, on their own.

See, while JavaScript is single-threaded as far as browsers are concerned (web workers? no never heard of them), you’re running this “simple” script on Airtable’s servers by virtue of it being an automation, which means node.js, which means an event-driven loop because surprise: your JavaScript is actually C++, which means your event handlers need to be surgical in how they approach their duties and – just as importantly – how they move out of the way the moment they’re done handling stuff.

A runtime that hangs, then throws its toys out of the pram because of a bogus await instruction might not be the root cause of your issue, but I wouldn’t bet against it; Sorry, but I do not like your chances based on the source-lines-of-code-to-cross-environment-breaking-error ratio at hand. But also due to personal experience because remembering my own learning curve with the fetch API makes me feel… void of more viable feelings. :grinning_face_with_sweat:

In the grand scheme of things, if this was a larger app nearing the end of some gung-ho agile sprint or however you people call other people staring at screens in a nonplussed manner for for hours on end these days, I’d probably suggest something more conservative.
I.e., if you’re from the future and go “hey, this almost describes my own problem, minus one or twenty thousand extra lines of code that I might have written or inherited prior to this moment”, maybe try fishing for silent errors by selectively declaring strict scopes inside of (potentially) problematic functions. Try it at least once before going back to torturing everything from the interpreter to the AWS silicon by dropping yet another cheeky try…await maneuver inside of you code.