Fixed a bug where deleting a row and then restarting the app before syncing would cause the deleted row to reappear. This fix is rollout out gradually and is deployed to 100% of free users and 33% of paid 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.
After this deployment time, We are experiencing AppSheet white-labeled app crashes for hundreds of users in an organization with thousands of users. Without any changes in App configuration.
The app keeps syncing for a while & crashes after some time. Not able to get diagnostics from the app & no errors in Audit logs
The support team is not yielding any helpful responses.
@lizlynch Are you able to help raise our case with a support team member?
What if we could use expression on the Launch imagem, this way we could use IFS(CONTEXT()) expressions and gave different animations in different context, such as a file generation, a completed task this way we could force sync and have a more animated and fun experience.
When querying from BigQuery AppSheet started sending the query as
WHERE (true OR true OR true OR true OR true) LIMIT 100000
instead of sending FALSE when the user setting Option 1 is blank, from 2024-07-23 08:51:45.807000 UTC . The setting was configured in the app a few weeks ago & the first instance of trues are only received at this time.
The expected filter to be passed in is
WHERE (`Table_Field` = @Table_Field OR `Table_Field` = @Table_Field1 OR `Table_Field` = @Table_Field2 OR `Table_Field` = @Table_Field3 OR `Table_Field` = @Table_Field4)
This behavior change from AppSheet - likely caused the app to load more data than intended - the Table with the filter had over 100000 rows & multiple images to be downloaded for offline use - might have caused the app to crash.
The issue was fixed when we updated the security filter, by including an IF condition to pass FALSE when the Option 1 user setting is blank.
@lizlynch & @AleksiAlkio , please pass along the bug to the respective team so it can be addressed. The Impact was not for all users, and it coincides with the 33% paid users indicated here so this could be part of this rollout.
I want to note here that the support ticket escalation was not meaningful. The support team continued to ask basic irrelevant questions, like does the app work on iOS devices? For an undocumented/disclosed change that affected a large portion of our users, the support we have received is abysmal. We lost a couple of workdays for a large portion of our team, and we had to dig a lot to understand the issue. We used to get a lot better support before Google acquired AppSheet. This is not the first instance of the support team not being able to provide any meaningful support during outages or issues. This just reinforces that AppSheet can not be a platform of choice when you are looking for reliability.
We had stable versions; We did a rollout more than 15 hours ago. Most users would have updated to the latest versions.
The issue was reproducible when I made the expression change.
The users are in a limited network area - there are chances some users are entering data in older versions & trying to sync now.
We had 17 rows with blanks & more than 100,000 rows in the table.
But the problem- the query was sent with ātrueā in place of conditions - when I checked the BigQuery job history
Can you update us on the rollout level? One of my customers is facing this issue on an important app for various weeks, and dozens of users are facing this behavior every week.
I need to tell them if this is being fixed soon.
Thanks for considering
Edit: in case that helps, here is the ticket number: 7-5402000036546