Set Variable & Server Action Timing Issue

Wappler General
#1

Wappler Version : 4.9.1
Operating System : W10
Server Model: NodeJS
Database Type: PostgreSQL

Expected behavior

For a Server Connect with param set to binding of a variable, changing the variable should execute the SC with the new variable value.

Actual behavior

After changing value of the variable, SC runs with the old value of the variable.

How to reproduce

The setup that we have was working fine before 4.9.1 (we were on 4.7.3).
SC is set to noload, with variable set as one of the GET parameter bindings.
On some event, I am setting the value of the variable, and then loading the server connect.
var1.setValue('123');sc1.load()
But the SC is running with older value of the variable.

The exact setup was working perfectly fine before the update.
I can share link to live dev server where this can be reproduced as well. @patrick

Delay to dmx functions
#2

@patrick Please help.
Its a huge application and many parts are breaking because of this timing issue.
Its mostly just server connect bindings that are affected.

#3

Just a guess, but it seems to me that the speed improvements are exposing a flaw in your structure. In other words, it may have worked before, but maybe just by luck and probably not consistently on all devices.

Those two actions will be attempted at the same time, not in sequence, right?

So you can either stick them in a flow inside two separate run actions, or just pass the parameters directly in the load method. I think either will be more in line with the intended behavior of Wappler.

#4

It is actually how Wappler works from what I know.
The actions are separate items in a regular event binding, supposed to get executed one after another.
Unless that behaviour has been changed.

Passing params directly is the last resort which I don’t want to do since its a really complex app and it won’t be possible to do it in all cases… Which is why I have the current setup.

Another option could be to convery it to flows, but again it will just add to the issue given the complexity.

#5

Sid, the actions added in a single event like as:

dmx-on:success="action1; action2"

are executed at the same time and action2 does not wait for action1 to complete before it starts. It has always been like that for these events, this has not changed.

#6

All my Wappler apps have this, and I have never seen it fail. And I have at least a dozen projects.
I have this particular app in production working fine, and dev is broken due to this new change.
So its probably something that has changed in 4.8 or 4.9.

Or like Ken suggests, it was working before by luck and now its finally broken.

Fixing this is going to be a huge waste of time and cost. If you or Patrick could take a look at the live app, it would be helpful and might save me a lot of time.

#7

One thing i am sure is that it was surely working by chance until now.
Probably the speed optimizations of App Connect made this noticeable now. Not sure how can this be ‘fixed’ as thats the default behavior of actions listed in dynamic events.

#8
#9

Personally, for the example above, I would add an on updated event for the variable to load the SC in that. That way it is definitely only going to trigger after the value is updated.

1 Like
#10

That is another solution, but again, does not cover all the use cases for me.
The complexity of the app and the numerous use cases is the reason why I would rather have someone from the team debug the behaviour… than starting with changing everything.

#11

@Teodor Could you please confirm if converting the event execution into a flow with each expression being a separate RUN step will make it sequencial (as Ken has suggested)?
I think the steps don’t wait for API and Server Connect calls. But if you could confirm the behaviour, I can probably start fixing this.

#12

Last I heard from Patrick, the run action will not know when the actions contained within are finished, so a wait command can help separate them since the flow itself executes in order.

But backing up a bit, how about running your server connect on updates of the variable? That way they will be properly chained.

#13

For example, on of the SC has two variables. In some cases I update only one of them, where this logic would work.
But in some cases I have to update the value of both, which would mean my SC would be called twice. Hence, can’t use this logic.

That’s just a disaster WAITing to happen. :wink:

If the flow thing falls apart as you say, only option I would be left with is to redo every single instance on a use-case basis.

#14

The steps in the flows run synchronously, which means they wait for the previous one to complete.
The only exception is the Run step, which runs asynchronously - which means running 2 Run steps in the flow they won’t wait for the previous one to complete.

#15

So it will basically execute same as inline setup that I have right now.
Damn.

I’ll have to waste so much time. :sob:
For all the stuff that has broken with updates, this has to be the worst for me.

#16

@patrick Any other ideas? Would like your take on this before I start making changes.

#17

I know, definitely not ideal.

Now that you know what’s happening, I’m sure you’ll find a solution.

1 Like
#18

I reported the issue related to that issue in Jan 2019. Its always been there.

#19

Interesting. Don’t think I have seen that post.
But now that the same thing has hit me… still finding the best way to fix it.

#20

We have made changes to 1 project where multiple dependent actions in an event were converted in a manner where they are not dependent.
As an example, the specific problem reported here, along with setting the value in variable, we are now also setting the same value in param in .load function as well.
Its going to take a bit more time to cover all apps, but will hopefully get there without any major production issues.