Issue with server action then-else condition

Wappler General How To
#1

Not sure if I am going mad or there is a bug here.
This is a edit from a larger server action.for managing multi user access for a future webinar

image
image.png695×464 31.2 KB

A fairly simple change of session values dependent on the date comparison {{$_SESSION.servertime < $_SESSION.lockwhen}} which is mirrored by the variable “ctest”

Variables are managed by sessions then returned to App Connect via Set Value with output checked

These values are then displayed in a simple app connect page

image

This action is polled every 10 seconds by an action scheduler

The debug variable only serves to show which “leg” of the condition has executed

Clicking the “Set Lock” button sets the “Lockedwhen” field/session variable to now+40 seconds to toggle the condition when expired

So here we see the action when the condition is true:

image

We see that the condition evaluates to true and the “then” leg is executed proved by debug = 1

image

As the time counts, when the server time passes the “lockedwhen” time then the condition ctest switches to false as seen below

image

HOWEVER the “else” conditions are not set by

image

These conditions still show the values set in the “Then” step, not the “else” with debug still set to 1 indicating leg “then”

Here is a short video clip of the code in action

serveraction-then-else.mp4 (67.6 KB)

The page can be found at

https://wapplervirtualacademy.com/multiuser/timecheck2.php

Anyone any ideas?

#2

I haven’t used “Set Session”, but using only “Set Value” with output enabled works for me.

Have you tried just using “Set Value” and remove the sessions?

image

When it exit the “Condition” it will carry over whatever the value of the variables.

#3

This is part of a much more complex action, sessions are the best solution in this case and this should work, sessions are effectively just a permanent server variable

#4

How are your “servetime” and “lockedwhen” variables stored? As strings? Then the comparison is text based …

You might want to convert them to number / unix timestamp first …

#5

yes, i format them as strings, both are yyyy-MM-dd HH:mm:ss as seen on the screen

The comparison seems correct as the variable ctest changes correctly from true to false, just for some reason the if/then/else still executes the true leg

While the variable ctest and the condition are identical i have tried just setting the condition to the variable ctest, same result though

#6

If you want to see if it is really going inside the “Else leg”, you can put in a “Response 500” so it will exit with the response text you have set. If it returns the response text, then it means it is going inside the “Else leg” and that the variables are not being set as you want. This is how I troubleshoot conditions.

#7

Tried it, else leg is not running even when ctest==False

#8

Have you tried forcing the condition to be false like e.g. Condition 0 ?
Then try Condition {{$_SESSION.ctest}} ?

#9

Thanks for your assistance @zitroware
Starting to think there is some corruption in the server action

I tried condition 0 and it did fire the else leg (got 500 response)

I then tried condition {{ctest} which i have done before and it was still ALWAYS running the else, never the then!

Put things back to condition

{{$_SESSION.servertime < $_SESSION.lockwhen}}

Still runs else every time, reverse of before the changes

I think there must be some corruption in the server action, i will rewrite it, perhaps differently and see how it goes, it’s not an urgent project, just something i was playing with for a future webinar

1 Like
#10

Well you are all going to love this, i have found a new fault correcting method in Wappler that nobody seems to have found yet.

I shouted insults and questioned the parentage of Wappler, told it what i was going to do with it is it didn’t stop messing me around, shouted a bit more then hit save.

Action now works!!!

I kid you not, I did not change anything, i just re-saved so I guess the truth is that perhaps making a few changes then reversing them caused whatever issue was in the action causing the fault to be corrected with that last save

2 Likes
#11

Whew :slight_smile: happy to see it’s all fine now, Brian!

#12

if it wasn’t 9.07 am i would open a beer now

1 Like
#13

Very pleased to hear you fixed the problem. Also looking forward to the webinar - it looks as if it’s going to be a particularly interesting one.

#14

Plan is “Managing data locks in a multi user environment”

1 Like