September 10, 2024

AppSheet Release Notes
1

Deployment Time: 3:00 PM PST

Features & enhancements

None

Bug fixes

Item Description
Bug Fixed a bug where data changes that fail to sync would sometimes reappear after being discarded by the user. This fix is being rolled out gradually. It is deployed to 100% of free users.

Rollout changes

None

Preview announcements

Preview feature releases enable you to try out new app features that are not yet fully supported. See Product launch stages.

  • No new preview features were released today.

In addition, the AppSheet preview program lets app creators try out new app features that are not yet fully supported. For more details and to opt-in, see AppSheet preview program.

1 Like
2

Hi @lizlynch

Thanks for the release.

Is this bug fix related to the one mentionned in this thread? (Our app is still facing this issue)

3

@Aurelien this is actually a different issue than that one. Since the prior fix didn’t work for you I wonder if this other bug is actually what you’ve been experiencing. Can you describe the specific behavior your customer is seeing?

Let me try to clarify the difference between the two fixes.

The earlier fix was about the reappearance of a row that had been deleted but not yet synced, for example:

  1. In an app with delayed sync and no automatic updates, or when working offline,
  2. the user deletes row “ABC”.
  3. The row “ABC” disappears from the app UI.
  4. The count of unsynced changes on the sync button increments by 1.
  5. The user refreshes the page or restarts the app.
  6. The row “ABC” incorrectly reappears in the app UI.
  7. Once the change is eventually synced, the row disappears again.

This more recent fix is about the behavior of the sync queue when changes are discarded, for example:

  1. The user makes a change that for some reason is unable to sync (maybe the schema has changed).
  2. The user tries to drop the change using “discard changes”.
  3. This initially appears to work, but some time later the sync queue count unexpectedly increments as the discarded change incorrectly reappears in the queue.

If the latter sounds more like your customer’s situation, this new fix should help once rolled out.

3 Likes
4

@Aurelien I found the support ticket from the ID number you gave in the other thread, it sounds like the issue is regarding deletion of rows directly in the data source rather than through the app? If so, unfortunately I don’t think either of these fixes is likely to help, as the first fix despite being about row deletion was specifically addressing a bug with deleting the row within the app.

If a row is deleted directly in the source but still appears in the app even after forcing a sync, I would suspect either Server Caching or Delta Sync performance options might be the reason.

Server Caching can cause a delay of up to 5 minutes for changes to be recognized in tables that are marked as “Read Only”. If the table in this case is Read Only and you have Server Caching enabled, I would suggest to turn it off.

Delta Sync can similarly cause a delay in changes made to the sheet being picked up by a sync if using Google Sheets as the data source. The delay in this case is usually more like 1 minute or less. If you’re using Sheets and have Delta Sync enabled, I would suggest to turn that off as well.

If neither of these are applicable we would probably need to do a deeper dive into the specifics of the situation.

4 Likes
5

Hi @Adam-google I will PM you very soon with more details, I don’t think it’s related to any of the situations you describe there :slightly_smiling_face:

2 Likes