Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Premium verification errors cause avoidable loss of data

41 views
Skip to first unread message

ittixen Bledsoe

unread,
Jan 8, 2025, 5:42:56 AMJan 8
to Automate for Android
I recently lost a bunch of data due to a "failed to verify premium" error.

I made a ranting review on Google Play and the response told me that premium verification is handled by Google Play, and to read the premium info page where I found no solution to my problem.

The thing is, nothing the user can do, could possibly address the consequences of this error. Even if I restore the verification successfully, the damage is already done.

For one thing, it immediately kills running flows as soon as it happens, which breaks multi-step processes that rely on each other / a specific order, leading to unexpected side effects, some irreversible.

Second, sometimes the successful verification after the failure is itself the cause of the problem. In my case, an "Audio record" block resumed after stopping, which ended up deleting the original recording by overwriting it with the newly started recording. By the time I even saw the error message, the verification already resolved, and the data was already lost.

Possible suggestions:
  • A grace period before stopping flows. Even when Google blocks the premium status, Automate can still take a while to let the user know what happened, so they can take steps to prevent the damage, either by resolving the verification error, or by manually stopping flows before the restrictions kick in. I think a few minutes should do in most cases, but better be safe with a few hours (e.g. when not looking at the phone and the verification isn't automatically resolved).
  • Making exceptions for some sensitive types of block (e.g. blocks that read/write to storage). This option is problematic, both because it's difficult to determine which blocks to exclude in advance, and because many processes depend on the relationship between multiple blocks. Not to mention it could let users use more than we paid for in some cases.

I'll add that I don't know how Google handles this process, and what hoops they force devs to jump through to make it work, nor do I know how Automate is implemented internally, so my perspective is naive and I'm sure there are issues I'm not aware of, but probably also better solutions that I can't think of.

ittixen Bledsoe

unread,
Jan 8, 2025, 5:49:37 AMJan 8
to Automate for Android
Forgot to mention a third suggestion:
  • Stop all flows premium verification fails, to prevent unpredictable behavior. Of course this option has its own obvious downsides, but in a way this is better than letting only some flows continue to run and possibly cause unexpected side-effect.

Henrik "The Developer" Lindqvist

unread,
Jan 8, 2025, 9:41:34 AMJan 8
to Automate for Android
Some way to cache the Premium status for a period of time before rejecting further flow starts is a feature on the to-do list, but i have yet to figure out a secure way of doing so.
The problem is that such a cache cannot be saved anywhere within the app since flows would have full access to it, making it very easy to copy/crack, i.e. piracy.

ittixen Bledsoe

unread,
Jan 10, 2025, 5:28:56 PMJan 10
to Automate for Android
I thought that might be the case. But if you can't find a way to delay rejection without risking cracking, can you do any of the other suggestions? Specifically, to allow the user to disable automatic resuming of running blocks after a restart? I realize now this is unrelated to the premium verification, but the issue of flows resuming automatically after a crash is directly affected by this (like in my mentioned case, where the app crashed and then restarted without premium status).

Henrik "The Developer" Lindqvist

unread,
Jan 11, 2025, 9:45:04 AMJan 11
to Automate for Android
Disable the "run on system startup" option in settings.

ittixen Bledsoe

unread,
Jan 11, 2025, 1:48:28 PMJan 11
to Automate for Android
WhatsApp Image 2025-01-11 at 17.33.47.jpg
This option is already disabled, and irrelevant. I'm not starting automate on startup. As I said, it's when the app resumes after a crash that this happens. I don't know how else to say this... Imagine the following steps:
  1. "Run on system startup" is disabled.
  2. User starts a flow manually.
  3. At some point, for whatever reason, the app crashes (this is not the problem, this is inevitable).
  4. When user starts the app again, whatever fibers were previously running (when it crashed), immediately resume running from the same block they were at when the crash happened.
  5. Therefore, if, for example, it was recording to a filename stored in a variable, it will now overwrite the file.
The point is not this specific example with recording audio (I found sufficient workarounds for this). The point is the very mechanism of resuming execution no matter what. The problem is that even if the user knows in advance that resuming a particular fiber could break something, they can't prevent it from starting, only stop it after it already started. It would be wonderful if it could be possible to disable resuming fibers when the app runs (not running the app when the phone starts, that's a different thing). But until then, I guess we just have to be careful to never create a flow that could break anything after crashes.

Henrik "The Developer" Lindqvist

unread,
Jan 14, 2025, 9:34:28 AMJan 14
to Automate for Android
The problem is that the system can kill an app at any time, usually in a low-memory situation, so not resuming flows would make them very unreliable.
As said in your other post, there's way to work around your overwrite issue, see: https://groups.google.com/g/automate-user/c/_udT5eBR1Kg
Reply all
Reply to author
Forward
0 new messages