V0.3.113.20210203 and emails [variables defined with initial values reset upon web request response]


#1

There’s a problem with this version and sending the body of an email in a variable.

The piston is set up like this:
A variable is set to String (text) with an initial value.
It is used to send to Pushover as the body of the message, and also sent in an email as the body of the email
During the execution of the piston the variable value might be changed.
The pushover message is correct, it receives the modified text.
The email receives the initial value of the variable, not the changed value.

In v0.3.110.20191009, the email received the correct (modified) value of the variable.

Here’s the log of v0.3.110.20191009
05/02/2021, 11:33:56 +974ms
+1ms ╔Received event [Home].test = 1612542836970 with a delay of 3ms
+41ms ║RunTime Analysis CS > 19ms > PS > 6ms > PE > 16ms > CE
+44ms ║Runtime (40234 bytes) successfully initialized in 6ms (v0.3.110.20191009) (42ms)
+45ms ║╔Execution stage started
+52ms ║║Cancelling statement #50’s schedules…
+67ms ║║Calculating (string) The is the changed message variable detected by + (string) Home >> (string) The is the changed message variable detected by Home
+70ms ║║Calculating (string) The is the changed message variable detected by Home + (string) . >> (string) The is the changed message variable detected by Home.
+74ms ║║Executed virtual command setVariable (1ms)
+104ms ║║Sending external web request to: api.pushover.net/1/messages.json
+630ms ║║Executed virtual command httpRequest (548ms)
+1153ms ║║Executed virtual command sendEmail (515ms)
+1164ms ║╚Execution stage complete. (1118ms)
+1166ms ╚Event processed successfully (1166ms)

Here’s the log of v0.3.113.20210203
05/02/2021, 11:56:33 +148ms
+1ms ╔Received event [Home].wc_async_reply = httpRequest with a delay of 4ms
+1027ms ║RunTime Analysis CS > 976ms > PS > 18ms > PE > 33ms > CE
+1030ms ║Runtime (39846 bytes) successfully initialized in 18ms (v0.3.113.20210203) (1027ms)
+1031ms ║╔Execution stage started
+1360ms ║║Executed virtual command sendEmail (275ms)
+1369ms ║╚Execution stage complete. (338ms)
+1385ms ╚Event processed successfully (1384ms)
05/02/2021, 11:56:31 +507ms
+1ms ╔Received event [Home].test = 1612544191507 with a delay of 0ms
+42ms ║RunTime Analysis CS > 17ms > PS > 5ms > PE > 19ms > CE
+44ms ║Runtime (39833 bytes) successfully initialized in 5ms (v0.3.113.20210203) (42ms)
+45ms ║╔Execution stage started
+50ms ║║Cancelling statement #50’s schedules…
+55ms ║║Calculating (string) The is the changed message variable with timeout = + (string) 2 >> (string) The is the changed message variable with timeout = 2
+61ms ║║Executed virtual command setVariable (3ms)
+79ms ║║Sending external web request to: api.pushover.net/1/messages.json
+88ms ║║Executed virtual command httpRequest (20ms)
+89ms ║║Requesting a wake up for Fri, Feb 5 2021 @ 11:56:55 AM EST (in 24.0s)
+94ms ║╚Execution stage complete. (49ms)
+95ms ║Setting up scheduled job for Fri, Feb 5 2021 @ 11:56:55 AM EST (in 23s)
+103ms ╚Event processed successfully (103ms)

You can see that in the the old version, it got sent right after my call to Pushover, so it emails the correct (modified) contents of the variable. In the new version, the SendEmail is executed in a second pass of the piston. So it must be reverting to the “initialized” value of the variable.

I tried several variations for the initial value and type of the variable:

  1. Set the message variable to dynamic with an initial value does not work, it sends the initial value.
  2. Set the message variable to string(text) but leave the initial value blank does not work, it sends the initial blank value.
  3. Set the message variable to string(text) but set the initial value to “Nothing selected”. This works, and saves the value of the variable in a comment next to the variable in the definitions section of the piston.

So if you have to have an initial value for the variable but it could change to something else later, then you need to do method 3, and then set the value of your variable at the very beginning of your code.

Update: The screen shot above is of the code that finally works. I tried to switch it back to my original setting of an initialized string variable, but I didn’t get the email. My log file shows I’ve exceeded my allotment of 50 sending emails from webCoRE. I forgot there was a maximum. Oh well, no more testing today for me. :sob:


#2

Interesting scenario. So this is something that probably would have happened before with a piston that used a wait – in this case a web request that was previously done synchronously is now asynchronous which is not guaranteed to be backwards compatible. @E_Sch was the change to async http required or was it an optimization?


#3

On both HE and ST, it holds the thread for the duration of the web call. So it is expensive (ST in $$ as they pay for cpu), HE in losing a thread of the cpu (there are only 4)). In HE I had to do this.

My view is the piston should be updated to save it to an uninitialized variable, as inserting a sleep or another call that may cause a sleep could do the same thing…


#4

I agree.

@allanp thank you for thoroughly testing and documenting this change. Glad you came up with a good solution.


#5

Thanks, I only have a few simple pistons that should be easy to switch to uninitialized variables.