We have some pages/workflows which edit rows in a Data Table. I’ve noticed that sometimes, a write will succeed, but the page we are redirected to looks like the values haven’t been updated. Then, I reload the page and the values are set to the expected value.
It looks like there is a slight delay for the effects of a write operation to show up in a read operation. Does this make sense based on your Data Table implementation, or are we seeing something else?
Read-after-write should be guaranteed for Data Tables. The first thing I’d check as part of debugging is to have the workflow debug panel open for the page you’re redirected to and see what the raw results are from the Table: Get Rows node. This would also confirm whether or not the workflow is even triggered as opposed to the browser showing you a cached page.
Ok, I just tried your suggestion; opening the workflow panels for the PUT operation, the workflow panel for the GET operation, and the view panel for the page that the GET operation returns.
It does look the way I’m describing; the Data Table write returns successfully, confirming the values that were PUT’ed from the edit form.
In the GET workflow, the query appears to return slightly-stale data; it still shows the value from moments before. The page panel also confirms this in the pageData variable.
If I reload a few seconds later, I get the values that were sent in the PUT.
One thing I noticed - we’re performing the query inside a Custom Node. I don’t think we’ve explicitly enabled any caching, but if there is some caching of Custom Node results, I guess this could explain it.
Thanks for doing the quick test. There’s no caching at the custom node layer, so any caching would be the browser being overly helpful, but since your workflows all triggered, that doesn’t look like the case.
As a follow up test, can you put a Table: Get Rows Node immediately after the Table: Update Rows Node. I’d like to see what happens with an immediate read after a write in the same workflow.
Ok, just tested. The inconsistency disappears when I add the Table: Get Rows Node. I tested many times with various combinations of values. Then I took the new node out, and the inconsistency came right back.
Is your redirect Endpoint Reply Node in the same line of execution as the Table: Update Rows Node? Does the workflow fork execution where the Update Node and the Reply Node are on two separate paths?
Yeah, same line of execution. There is the Table: Update Row node, then Endoint Reply node, then a Debug node.
Upstream, there is a branch in this workflow if the user is unauthorized (which rejects the update entirely) but I’m about 99% sure that this is not relevant.
When the inconsistency disappeared, the flow was Table: Update Row, Table: Get Row, Endpoint Reply, Debug.
Roughly how much data are you updating?
One row of a Data Table with 9 columns: 6 string columns (maybe 40 characters max, per column) and 3 boolean columns.
Actually, I have a slightly different observation now: it looks like the Table: Get Row node does not prevent this inconsistency from appearing.
However, I did discover something. The database-get result (pre-update) was being stored in our payload, and the workflow that responded to the GET request was storing the database-read result at the same path. Our PUT workflow redirects to the GET workflow. I have changed the names of these variables so that the use entirely different variables, and I cannot reproduce the issue now.
I’ll keep testing to make sure it’s not just a fluke that I cannot reproduce.
Hello again,
It looks like this issue is still happening. To summarize, I have a Data Table write in one workflow (with a read immediately following, to confirm that the write was succesful!) and a Data Table read in another workflow. The Data Table read in the 2nd workflow appears to be returning stale data.
In my scenario, there is one workflow triggered by a PUT and another workflow triggered by a GET. Our page sends the PUT using AJAX, then performs a GET by changing the page URL.
Debugging the Losant workflows, it appears that the workflow responding to the GET has stale data, i.e. is returning with the row as if the previous write had not occurred. This seems to rule out the possibility of browser caching.
In every instance I’ve seen, refreshing the page (reading one more time from the Data Table) gives the expected value.
It’s possible that I’m doing something incorrectly in my workflow, but I’m not sure what; everything looks correct to me, except for the Data Table read results.
This whole issue is quite intermittent and rare; it took me about 50 attempts of toggling boolean values to see this happen.
This may be a long shot, but is it possible for you to reproduce this and provide screenshots with timestamps of the updates?
Just to confirm, you are only rarely seeing this behavior; it’s not happening in any consistent manner? I’m trying to reproduce with no luck.
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?
Ah, geez. I think I know what’s going on here.
I’m doing an AJAX call, then setting the window URL afterwards. It’s certainly possible that the AJAX call hasn’t hit the server by the time the GET request is performed, so it’s not inconsistency on your database’s part; it’s a network race condition.
I’ll fix that up and see if that eliminates the issue.
