Check on the other instances currently running / add wait queue

is it possible to check the current instances of the scenario that are running from within a scenario. Ideally I’d like to add something so it can wait until the previous scenario trigger has run before it starts the new trigger. In Zapier they had the wait queue which is what I’ve been doing over there.

Basically it’s useful when a scenario gets triggered multiple times by a web hook in close succession. At the start of a scenario I have it checking a database to see if an extry already exists and then it just updates that entry, otherwise it creates a new entry. But sometimes the first hasn’t finished executing before the next starts so both instances create a database record creating a duplicate. This was a question I had asked in Discord. Someone replied about doing upsert to the DB instead which works sometimes but other times I’m not adding a record to a database but another node that doesn’t have upsert ability.

I’ll check with the developers on that—it’s an interesting question.

In the future, queueing functionality will definitely be implemented, but for now, you can use a workaround by leveraging the Latenode database.

When a scenario is launched, a record should be created in the database indicating that the scenario is currently in progress.

Each time a new scenario is triggered, it will first check the database. If a record with the “in progress” flag already exists, the new scenario will not start until the previous one is completed.

Ah yep. That’s a good idea. And then just have a wait loop or something that checks every 10 seconds if that variable has changed?

  1. So the scenario starts.
  2. It checks for a global variable called in-progress which is either true or false (because I can’t work out how to make the database work lol)
  3. If it’s true then wait 10 seconds, check again and keep looping until it’s false. Then if it’s false move on.
  4. Set the global variable to true.
  5. Do the stuff in the node.
  6. Set the global variable to false and the next one iterating can start.

My concern would be if it errored out while I was asleep and never set the variable to false again, then I had a scenario running for many hours burning through heaps of credits.

It’s better to do it like this:

0. Create a queue in DB in this section: https://app.latenode.com/database

2. The first scenario should start with the Webhook trigger and save incoming request data to DB using the “Database → Create Object” node

3. The second scenario should start with “Trigger on Schedule” once per few seconds, read data from the DB using the “Database → Get Objects” node

CleanShot 2024-09-13 at 19.52.16

4. Right after the “read” operation - you need immediately delete one object that you will process in the current execution from the DB queue

5. If the queue in the DB is empty - stop the scenario execution using filter on a route

Cool thank you. The only donwnside I can see with this is it’ll use up heaps of credits each time the trigger on schedule runs.

My solution for now which doesn’t seem to use up any extra credits:

I’ve created a nodul which gets a timestamp from a global variable. It compares it to the current timestamp and if it’s longer than the interval I set (which is 15 seconds in this instance because that’s roughly how long that scenario takes to run each time) then it sets a new timestamp on the global variable and continues.

If it’s within 15 seconds since the last timecode was set it adds another 15 seconds to the global variable and waits for whatever the difference in new timestamps are.

Happy to share the export with anyone else experiencing the same challenges.

Obviously, it’d add unnecessary wait time if you added it to heaps of nodes, but you could probably add a unique scenario ID in there if that was the case.

Hey team,
I don’t suppose there has been any further thought around adding a queue node into the mix? Would be really handy. I’ve got my work around above (with a bit more complexity in it now) but I still run into issues sometimes when my estimate of how long most scenarios take to execute is wrong. So would be great if there was something built into latenode.

Hi! I spoke with the developers today, and they mentioned that a queuing system is expected to be implemented in about a month, possibly a little longer.

The main thing I wanted to share is that it’s on the way - and relatively soon.

Amazing! Thanks heaps

1 Like