Function for delay

Product Suggestions
,
1

Hello Team,

it would be very helpfull to have a delay function , I know there is like a work around but I think will be better to have one

we have like severals triggers in a single button, sometimes action from the previous trigger take time to be completed , and the next trigger needs those actions to be completed in order to be executed, so this is causing us to click the boton more than one time.

it could be on the expression editor, or it could be a run device function, or an action item.

2

I hope for an even better solution for those issues with slow function.

If I read this suggestion, I have connector functions and tulip table interaction in mind.
So in my opinion the solution should be something like promises in javascript. So the function waits for a result and then has two possible outcomes: resolve or error

Implementing something like that would allow to always have a result (good or bad) and then handles it.
A good example is an API. In the moment you have the result, the next function would work. No matter if its 200ms or 6s. No guessing involved :wink: (what if it needs even longer today? always wait longer even if its a waste of time?)

Or do you have other scenarios, where you need a delay?
You could build a custom widget, that has a number parameter (Miliseconds to wait) and an event when time is up. That event can execute triggers…

3

@ChirristopherOficial, this is a great suggestion, thanks for sharing this. I have a quick follow-up ( @thorsten.langner, you weigh in here too): What you’re describing sounds like a performance issue, with triggers not fully functioning because of unmet dependencies in previous triggers. This is highest priority for our product and eng teams right now, and we’ve made a lot of progress here recently. That said, if there weren’t performance issues, would you still want a delay function?

4

@ChirristopherOficial this is a very interesting question as there are a few potential answers as well -
Triggers should only run one after the other, waiting for the previous to finish before doing the next. However, it sounds like you’re experiencing an issue where something outside of Tulip is taking a little while to update (like a database, or something) and so the next trigger doesn’t automatically know that the previous one finishing actually accomplished all the tasks it needs. Is that correct?

If all these Triggers are doing functions within Tulip (writing to table records, changing variables, etc) then it should be such that a trigger will absolutely wait until everything before it is done and has reported no errors.

Regardless, you definitely shouldn’t have to click buttons more than once in this kind of scenario. I’m gonna log this wait functionality as a request ticket (we might have some things on the horizon soon that can help), but do you mind elaborating a bit on what is not being done before the next trigger needs to use it?

5

To me it’s not only performance issues.

I have two scenarios, that are common, the first one has also to do with performance, but not necessarily
only.

  1. If you use a looper widget, it will throw the tasks on a stack. These tasks are then processed immediately, but may take longer then building the stack.
    If you have another trigger after starting the looper, it will wait for the looper (building the stack) but not for the processing of all tasks initiated.
    So if the looper is done, but the tasks are not all processed yet, you will have two issues:
  • The process bar is done, but the tasks are not
  • The next trigger functions will work with wrong data, because they start after the stack is done, not the tasks itself.

There is a solution, but that has to be in mind of the developer: Do the looper as last trigger function, and put all following tasks in the looper end task (or next step, triggered by the end task).

  1. Connector functions mainly APIs may need longer. This is an external performance issue, but not in TULIPs hands. So you actually have to wait for the result (not a given time, but the response!)