This is the function I use:

    function timeout(ms) {


       return new Promise(resolve => setTimeout(resolve, ms));


    }

then you can use like:


await timeout(5000)//waits 5 seconds

hmmm…

@openside - why do I get an error when I try to use that in a Airtable block.


“Cannot find setTimeout()”

I don’t believe the Scripting block has the limit on API calls that you would have if you were writing API code to be executed elsewhere, mainly because you’re not calling the API when using the Scripting block. The API is the means of accessing Airtable when you’re outside of the Airtable interface. The Scripting block is internal, so there are no such restrictions.

Other way around @Justin_Barrett; I’m using a 3rd party API with a restriction. Alpha Vantage - for stock market prices.

Do you know why the setTimeout() is not found?

Sorry. I thought you were referring to the Airtable API, not a third party API.

I’m just getting reacquainted with JavaScript myself, and haven’t yet hit a situation where I’d need a delay, so I’m not sure why setTimeout() isn’t available.

@David_Koontz - their editor gives a warning, but the code runs fine. Their editor just doesn’t recognize it. You can tell it to ignore the error warning if you want by right clicking over it and clicking on the ‘Quick Fix’

I’ve run up against what I believe to be a rate limit in the scripting block API. When I modified my script to slow calls down to about 5 requests per second, the script worked.

I’m getting this Error:

ERROR

ReferenceError: Can’t find variable: window

asyncFunctionResume@unative code] main anonymous s@blob:https://block--v-xd-mn-xix-b-lud-p5--06e4o42.airtableblocks.com/467c6f74-ac94-41bc-9fe7-45746e655847:1:2815

Any ideas why it works for you but not me?

Strange, because I’ve got a script that does a ton of stuff to my base, and I haven’t encountered any timing-related issues that I know of. Again, this is just using block-native features to only read and modify Airtable records, not calls to external APIs.

I was also using only block-native features and no external calls.

Have you been submitting more than 5 calls per second to createRecordsAsync(), updateRecordsAsync() or deleteRecordsAsync()? That’s how I ran up against what I believe to be an unpublished rate limit. In my script, I didn’t need to await the return values so I was running them in parallel instead of in series.

Remove window. should just be calling setTimeout() like in my code example

Thanks @Justin_Barrett - again, the restriction is on the API I am calling Alpha Vantage.

I’ve got code that is working this morning. From @Bill.French

function timeout(ms) {


return new Promise(resolve => setTimeout(resolve, ms));


}

await timeout(1000); // 1 sec pause

But I swear I had the same code last night and it did NOT work… so I’m stumped as to what magic dust makes it work today. Even with the IDE given the error codes about setTimeout().

I’m using a mix of create and update operations, though in my case I need to use await on all of them because I’m linking between various records as they’re created, so they probably aren’t triggering in quick succession.

I doubt that you could run more than 5 requests per second when using await. I didn’t see the problem until I started to run the requests in parallel. I consistently got the generic “Something went wrong” error. Then I slowed down my script to just over 5 requests per second with no other changes and the problem disappeared. I’d be curious to see if anyone else can replicate the issue.

That’s exact same code I shared with you originally :winking_face:

And where I found it as well. But there is an issue here given the subtle indicator from the editor that this is not supported. And I wonder if this morning’s API issues align with @David_Koontz failure experiences.

Do you think that the wavy red underlines in the editor means that setTimeout() is not supported? I get those wavy red underlines all the time for things that clearly are supported, so I tend to ignore the wavy red underlines after a while. Or is there something else?

For me, setTimeout() works as expected. It waits the specified amount of time and then runs the provided function with the provided parameters.

setTimeout(echoText, 1000);


setTimeout(echoText, 2000, "Hello, World, again!");


await input.textAsync("Just something to keep the script from ending");


function echoText(myText = "Hello, World!") {


    output.text(myText);


}

setTimeout(echoText, 1000);


setTimeout(echoText, 2000, "Hello, World, again!");


await input.textAsync("Just something to keep the script from ending");


function echoText(myText = "Hello, World!") {


    output.text(myText);


}

That’s exactly what it is suggesting.

The **red underline** has been a tradition in IDE for 20 years… it has various meanings… but general a reason for the developer to stop and fix it.

I wonder why the Airtable IDE (tool) is fooled??? I’m guessing it is the difference between parse time and run time - the setTimeout() method must be found at runtime for it to work… but at code parse (interpretation) time - it’s an error.

One of my JS experts mentioned this aspect this morning.

Yes @Bill.French I’ve checked and rechecked … same code! I can’t recreate the state of my system the other night when it was failing and I chased a rabbit down the wrong trail… but I swear it was not working… now it could be one of many reasons (maybe none the timeout method) cause I’m a newbie with embedding JS like this.

But now that it’s working I’m continuing my attempt to get stock quotes via 3rd party (Alpha Vantage http://alphavantage.co) - I’d like to know what interfaces I’d need to support to make my code a first rate Airtable block. (any info?)

Simple answer - Script Block is an infant, not even a toddler yet. Surprisingly, it runs very well despite it being only a few weeks old.

Thanks for the info. I don’t use an IDE.

I have seen wavy red underlines in other contexts for years (Word documents), and they usually mean that the grammar checker thinks the section has a grammar problem. Sometimes there really is a grammar problem, and sometimes there isn’t. When I know the grammar is correct, I ignore the wavy red underlines.

My code editor does not have a grammar checker, but it does color-code text according to a selected grammar, which helps in discovering some grammar problems.

In the Airtable scripting block, I assumed that the wavy red underlines were also a grammar/vocabulary checker. I find that Airtable editor’s grammar/vocabulary checker is so overzealous that it gets in my way. I do use it to check to make sure the grammar and vocabulary is correct, but I also feel free to ignore its suggestions.

I have not seen wavy red underlines directly indicating that a particular feature is unsupported. Rather I take it to simply mean that the grammar checker does not understand the section, which may or may not mean that the features lack support.

I’ve been very happy with Scripting block, and I’ve gotten a lot of enjoyment out of it. I’m not surprised at how well it runs–I expected that level of quality from Airtable.

LOL! I believe you. This is software.

Well, you need URLFetch() to pull that off, but “first rate” is a subjective question.

Yes the Scripting Block does a really good job for being such a new feature. I AM AMAZED. I worked with it for hours and never had any issue. For a web app - this is unheard of reliability - not seen since Netware was turned off. Someone knows how to write some great code that recovers all it’s memory well.