New Bug Encountered: With Delta Sync on, manual change to sheet reflects in App table but NOT in UI

This needs fixed.

I have seen this in a production app-to-app interaction. The idea has been placed on hold until this issue is fixed.

I have reproduced the above production problem in a test app-to-app interactions and have previously submitted it in a bug request a couple months ago. I tested it this week and thought it was fixed.

Now, I am noticing it with simple manual changes to the sheet. (Images are below)

Basically, while testing, I am changing a value in the sheet manually. I sync and the value is reflected in the app table as indicated by the โ€œView Tableโ€ function. However, the value does NOT reflect in the UI. It seems to me that if the app contains that value in the app-side table it should also be reflected in the views - immediately!!

This is where I think the bug is occurring - app-side updates - and it seems to be related to having the โ€œDelta Syncโ€ function turned ON.

I think if I wait long enough, it eventually is updated in the appโ€™s UI view. But definitely a refresh of the Editor page updated the app.

If I turn off โ€œDelta Syncโ€, changes are reflected as soon as I sync - each time.


Example images below


In row ID=2, updated Amount from 25 to 20

After Sync, Perform a โ€œView Tableโ€ function, table data reflects change to 20

UI view still shows 25 as the value - even after several syncs and several minutes

After web page refresh, UI view then shows the correct updated value of 20

1 16 422
16 REPLIES 16

Steve
Platinum 4
Platinum 4

Iโ€™ve seen stuff like this before where its simply the browser caching data. Have you checked if you can stop the browser caching for specific sites? Also it might be worth performing the above experient on different browsers to see if it affects them all.

Simon@1minManager.com

It could be but I donโ€™t think so. As indicated the Editor โ€œView Dataโ€ function DOES reflect the new value. So the change made it into AppSheet - more specifically the data table in AppSheet. Yet the new value is NOT being reflected in the UI view. This means the value made it through the page caching.

Turning Delta Sync off eliminates the delay. Value shows immediately on a Sync.

I have noticed the same behaviour. Also, whenever an action updates a row (Not a bot). It takes a while (Approx 20 secs) to reflect in the app if I donโ€™t force sync. I have a security filter that will remove the rows with a simple condition like below.

Here the database in sheet is updated and set archive status to archived.

It still shows up here Until the sync is completed.

This kind of behaviour used to be there when I use Automation Bot when the changes are made on the server-side and it takes a while to show up on the app UI. But in this case, I use an action button just to change the Archive status.

If the action is activated by a button or on a From Saved Behavior - basically anything on the device side, it should show up in the app nearly immediately. The only exception might be a lengthy calculated value.

If you are seeing such delays, you might need to take a closer look at the processing to see what is causing the delay.

Itโ€™s a Grouped action with 2 actions

  1. Itโ€™s just updating value in current row
  2. Updates few child record.

The first action will set column as โ€œarchivedโ€. And security filter is just [archive status_column]<>โ€œArchivedโ€

Thereโ€™s no complex formula here. Actions always updates immediately. Right now itโ€™s behaving like a Bot update. I have used really complex expressions and used to work immediately on app UI.

That is not a bug but how delta sync works .

True.
We just canโ€™t have it all

On each sync, the AppSheet server tries to determine if the table has been updated after that timestamp. Only then is the table data retrieved from the cloud data source.`

I think, guys, you are missing a very important point!! Inspecting the table data shows the NEW value updated. See the images above.

Additionally, manual Syncs DID NOT bring in the updated value.

If the value is showing in the app-side table, I believe it should be reflected in the UI views - immediately. Why have the updated value on the device and NOT show it??

I just got off a Zoom call with a client where an entire NEW row was showing in the sheet and the โ€œView Dataโ€ for the table but was not reflected in the UI table view. After several minutes, the row appeared. Multiple manual syncs did not correct the missing row. It should have.

I guess I am assuming that when in the Editorโ€™s Table tabs and I click โ€œView Dataโ€, I am seeing what the DEVICE thinks the data is and not what the server reflects. If that is correct, then this is a bug.

This is what I was going to point out, but then I kept reading and saw you mention it. I believe your assumption is wrong here. In lots of cases it seems to be the same (like security filters), but Iโ€™m betting that the โ€œview dataโ€ button doesnโ€™t care about the delta sync option, only the app itself does.

When youโ€™re working with multiple apps (or multiple platforms) that are all using the same data source, delta sync causes lots of issues. Iโ€™ve seen it many times before as well. Just say no to delta sync.

I think I agree. But then what is the โ€œView Dataโ€ function supposed to represent? Device-side data, server-side data, neither?

It seems the Editor itself should be subject to client side behavior just like any device is - I mean after all there are still servers the Editor has to interact with.

Regardless, as you have confirmed, there are issues with Delta Sync. I think there are two unknowns, at least for me, that we as a community should understand about Delta Sync:

  1. What state of the tables does the โ€œView Dataโ€ represent?
  2. What is expected of Delta Sync for updates made by external processes to the app (could be manual, 3rd party or even other AppSheet aps)?

Bottom line - Delta Sync can be an important feature for many apps.

I have now witnessed with two clients in two different apps, delays of several minutes - one with frequent delays of 10 minutes! Both were from app-to-app interactions and I believe both related to Delta Sync option being on

I thought my observation in this post would help identify a resolution but it seems the Delta Sync problems might be more than I observed.

I think we can all agree that Delays into the minutes for data changes is unexceptable. Delta Sync needs to be fixed and reliable in all use cases. Itโ€™s important!

I am going to disagree with you here. By turning on Delta Sync you basically told the system that a delay in seeing new data actually is acceptable. That it is acceptable in the name of faster sync times.

I donโ€™t think you encountered a bug, and I donโ€™t think Delta Sync is broken and needs fixed. I think it should just only be used in certain scenarios. And your scenario doesnโ€™t sound like it is one of them.

Should the documentation on Delta Sync get fleshed out more, to include more warnings about using it in multi-app situations, among other things? Yah, probably. Oscar already linked this article in question, and quoted a portion of it, but let me post the entire section about Delta Sync:

3X_f_2_f2f1a7d65af69ab04601a88e735dd2b5e6dbd6ff.png

Thatโ€™s a pretty large โ€œCautionโ€ section!


Device-side for sure, as it takes Security Filters into account. Or at least a close approximation of device-side. Keep in mind that what we see in the editor/emulator has always been slightly different than what is actually seen in the app. Iโ€™m sticking with my guess that whatever request is sent when you click โ€œview dataโ€ just doesnโ€™t even consider the Delta Sync option. Because why would they build it like that? Youโ€™re not concerned about sync speed when clicking โ€œview dataโ€.


All in all, Delta Sync is an option meant purely to improve sync speed, with plenty of cautionary messages about why you might not want to use it. And from the above doc, it appears that its method for determining when to sync is quite imperfect from the get go. Iโ€™d highly doubt that it would even be feasible for them to improve on Delta Sync.

I think weโ€™ll have to agree to disagree. Not a problem! Itโ€™s all good.

This bug isnโ€™t really about Delta Sync itself. Iโ€™ll give one last thought on that belowโ€ฆ

All along my contention has been that Delta Sync IS affecting how data shown within the โ€œView Dataโ€ results is reflected in the app views. I agree that โ€œView Dataโ€ may not behave exactly like a device but as you said it should be a close approximation. The editor/emulator is all I have to analyze the delay seen in production apps and I believe what Iโ€™m seeing there is what is contributing to the 10-minute delays we have been seeing in production apps.

I forgot I still had the video. I linked it below maybe it will clarify better what I think is a problem?

https://drive.google.com/drive/folders/1JCVuNGCJRTAytSwya72W9JqC2_tJubxd


My thought on Delta Syncโ€ฆ

The whole intent of Delta Sync is to update ONLY the tables that have changed instead of all tables in order to speed up Sync. The feature should work as advertised in all situations where it is technically possible - definitely in Google Sheets and definitely without a ten minute delay in updates (that is NOT an exaggeration).

In the โ€œcautionโ€, it states that the LastModifiedTime property โ€œis not perfectly accurateโ€. That doesnโ€™t mean it is not kept and I donโ€™t think it would mean that it is off by minutes. I find it hard to believe that Google is not aware of changes to its sheets as soon as they happenโ€ฆat least within seconds. It seems to me we should expect Delta Sync to work nearly flawlessly in Google.

From my reading, these cautions are intended for data sources OUTSIDE of Google since AppSheet supports many other 3rd party data sources.

I donโ€™t agree. This was implemented for the purpose of speeding up Sync. Larger apps can benefit from it greatly. It needs to work! For the Enterprise scene, itโ€™s important!!

Top Labels in this Space