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