@Arthur_Rallu @Adam-google
This is not happening recently, but it was there since new desktop UX was released formally.
We have deeplink action with special parameter to let the app to sync (=at xxx params). This always works with the legacy UX.
However, when the same action was invoked inside the new desktop UX, this deeplink action is not working as intended. SYNC is not going to happen.
While I have been testing, it became obvious that this problem would happen when there is pending sync at the point of time the deeplink (with force sync) is invoked.
We have a bunch of occasion where we wish to let the users wait until sync is completed to interact with app. This problem seems to be a peanuts, but for us, this brings the significant magnitude to the user of our apps.
Could you look into the case?
I believe you can re-pro this problem with your apps on your own.
4 Likes
The thing which is strange to me is the GROUPED action case.
First action is to make data changes and then deeplink action (with forcing sync) is invoked after that. What the strange thing is sometimes the SYCN is happens, but sometime it does not…… This makes us more puzzled.
At the time the force sync deeplink is invoked, the previous action to make changes is unsynced. But sometimes SYNC happens, but sometime it does not .
Whatever reason, I would really appreciate if you could spare your time to investigate and diagnose the issues.
1 Like
@Arthur_Rallu @Adam-google
We have grouped actions with data changes followed by deeplink action with parameter to let the apps sync. This action is going to trigger the automation (with data change event) and BOT will invoke the API calls through GAS and get the returned value. The GAS logs indicate the script run successfully, however, almost 50% is failing to save the returned value with the subsequent steps.
This is not going to happen with the legacy UX, but only happening to New Desktop UX alone.
I m pretty sure based on the failure of saving the values with the automation is because of bugs/glitch associated with new desktop UX. We have to turn off (only if this condition is true) option to be “false” for the deeplink action as it obviously seems to be a source of the cause of the issue. All in all, the deeplink action (to force sync) with the desktop UX is surely unstable in various aspect. Can you look into it ? This is causing massive negative impacts to our apps deployed with the new desktop UX…..
It’s surprising that being in desktop UI would affect the internal behavior of the automation. The only way I can think it could influence the automation would be the values that are sent in the add/update/delete request. If you check the audit log entry that triggers the bot do you see any difference between the values sent in the cases that succeed vs the cases that fail, or a difference when using desktop vs turning it off? Or anything else unexpected in the audit log in terms of number of requests or timing of requests?
It sounds like replicating the entire setup with the bot would be difficult, but I filed a bug ticket to look into the forced sync behavior on desktop and see if we can find any problem with how it’s handling queued updates.
2 Likes
@Adam-google
Thank you @Adam-google for your response. Strangely the audit log not throwing error message at all and it indicated all the steps including the saving the value to the data source step was successfully performed while no data was save to MYSQL.
I m not sure if this is going to affect to this errors but our apps are deployed to APAC region.
There are two issues, one is client side (no sync is going to be happening on some occassions). To the contrary, another issue is related to server side, the GAS returned value in the first steps, but the following step (to save values) is called but not saving values at all (without any error message).
Thanks you for continuing to investigate!
1 Like
Is it possible that the result is actually saved but then immediately overwritten by some subsequent sync or automation step? Does MYSQL have anything like a change log that shows from the DB’s point of view what happened to cross-reference with the audit log?
2 Likes
You can try context(view) for action, with desktop mode and split view, appsheet wil show the master view name, it is not the name of the detail view, but for the legacy and mobile view the appsheet show as a detail view name.
Not sure what you meant to say.
hi Adam
@Adam-google
Let me try to re-produce the issue with the simple & sample app so that you would witness the odd behaviors through the test app.
Reverting.
1 Like
@Adam-google
Let me split the issues and focus on the client side problem first of all.
See the below from the test app.
“new action 2” is a grouped action. First action will pass now value to now column and then force sync. If there is no pending sync, the sync (second action) will occur.
However, if there is a pending sync (“Now” action also update the now column value to current datetime) and the grouped action is invoked, the SYNC will NOT occur. It seems the second action (force sync) in the grouped action being ignored.
I hope I managed to demonstrate what the problem is, and I hope you could find the root cause and release a fix soon.
Once this client side problem is cleared, I wish to test the server side problem will still persist or gone.
2 Likes