Hi, I was able to reproduce again. That’s right, we are only seeing this behavior on about 1/50 instances of editing a data-table row. I haven’t qualified the statistics carefully; it’s somewhere between 1/30 and 1/200.
I was just able to reproduce; here are some screenshots with commentary.
First, here is some debug output from the workflow that handles the initial PUT request.The fields I have expanded are the result of reading back from a Data Table immediately after updating a row. The key values are
emailAlertEn being set to true, and
smsAlertEn being set to false. This workflow was executed at Monday March 26, 15:40:56 GMT-06:00.
The following screenshot shows the GET response, immediately after the PUT request above. The values coming from the Data Table correspond to the row values immediately before the PUT request. In particular,
emailAlertEn is set to false and
smsAlertEn is set to true.
This workflow was executed at Monday March 26, 15:40:56 GMT-06:00 (the exact same time as the PUT-response workflow above); in my estimation, it was executed after the workflow above (because this workflow is triggered in response to a GET request which occurs after the PUT request) but it’s not obvious from the timestamp.
The following screenshot shows the GET response, after refreshing, a few seconds after the above screenshot. The important thing is that the values have changed to
emailAlertEn: true and
smsAlertEn: false, corresponding to the initial Data Table write/read-back. So why are we getting intermediate, stale values in step 2?