Fatal action not deleted or renamed

[peter-moran]

I believe you have a bug where a "fatal action" file is not deleted or renamed. For me, this makes IFTTT not actually update the dropbox file, and thus the action is not played.

On the logs, I see:
"Action was fatal action - won't delete just yet - renaming"

In the code, I also see that the line for renaming the file is commented out.

AssistantComputerControl/AssistantComputerControl/actionChecker.cs

Line 230 in 80d49db

//File.Move(theFile, Path.Combine(Path.GetDirectoryName(theFile), newName));

When I hack IFTTT to create a unique file name every time, the actions start working again.

[AlbertMN]

Hi there. Here's a little backstory of the issue - if you're interested - otherwise, just go to the "solution" headline below

Backstory
This has been an issue since the very first version of ACC. However, the issue is not what you might think it is; in 1.2.0 I brought in "fatal actions": actions that result in the computer going into hibernation or being shut down. On execution of a non-fatal action, ACC deletes the action-file, but on a fatal action, it doesn't. This is done because the cloud service might not register the file being removed before it's terminated. This resulted in endless loops of the shutdown action, cause the file was deleted locally, but the cloud service thought it should be there, so it re-synced it, ACC saw it as a new file, and it shut down your computer, resulting in an endless loop.

The reason the line you refer to is commented out, is because it caused exactly that to happen; endless loops again. The theory was; if we don't delete it, but rather rename it, a file by the same name can be synced to your PC without trouble. The problem was; the File.Move method is the only way to rename a file. It removes the old file, replacing it with the exact same one, but with a new name. Once again, on fatal actions, cloud services didn't have a chance to pick this up, resulting in endless loops.

Now, one solution I came up with, was making files hidden. Cloud services didn't need to sync this, so I just made ACC not do anything if the file it's trying to read is hidden. The problem with this was; the file still kept its name (often "computerAction.txt"), and on some computers, this results in ACC not being able to execute any files with the same name until it's been restarted. So upon execution of sleep, hibernate, and sometimes lock, ACC would not be functional once "woken up".

It's also worth noting, that what you're describing ("... this makes IFTTT not actually update the dropbox file ...") doesn't happen for everyone. Some computers (mine included) just calls the file computerAction (x).txt rather than failing to replace it.

"Solution"
I think the next step towards solving this, is going through the 139 applets, making them have unique names (timestamp), seeing code-solutions haven't been super successful. This will take some time, but will be fixed.

Thanks for being alert and reporting bugs - helps the development a lot (even though this issue was known, better safe than sorry!)

Closing since the solution is known - all I need is to find the time to update all the applets :)

[peter-moran]

Very interesting, thanks for providing the details. I totally understand that a full solution will take time. Luckily I was able to use the IFTTT maker channel to create an applet that used a timestamp in the file name, like you mentioned, and it has been circumventing this bug perfectly.

[AlbertMN]

All the Google Drive applets have now been updated to feature a UNIX timestamp in the filename. Next up; Dropbox - this will take some time though.

[AlbertMN]

@peter-moran what assistant do you use? My computer doesn't seem to want the characters that the Google Assistant's {{CreatedAt}} ingredient generates as a filename - resulting in the file not being created at all.

[peter-moran]

I also used Google assistant and had the same problem at first.

I had to use the https://platform.ifttt.com/maker/ which allows you to run a "filter" step, which let me format the time stamp to be numbers only.

However, if you try this you will probably run into the issue that publishing a multi-step applet requires a paid account if you use the filter step. So you might need a different workaround.

[AlbertMN]

Google doesn't seem to be able to get that ingredient right... At first it was empty - didn't output anything. Was fixed 7 months ago, but now the format isn't allowed as a name. They're quite hard to get in touch with. Will see what I can do.

[peter-moran]

I believe the main problem is that IFTTT now uses a date description that contains characters that are invalid on most file systems, eg :. https://www.reddit.com/r/ifttt/comments/75v9er/help_ifttt_is_saving_images_on_dropbox_with_a/

I have noticed something interesting though, the files do still show up on the Dropbox website. They just don't get synched because the invalid file name.

[AlbertMN]

That is indeed interesting - didn't know that. Writing to Google right now, and will post in the IFTTT reddit forum. The ingredient "CreatedAt" is generated by Google, and IFTTT has nothing to do with the content. IFTTT won't be able to fix this, but a nice feature would be for Dropbox to get their own similar ingredients to fully allow unique file names.

[AlbertMN]

Reddit post urging IFTTT to make universal ingredients, such as UNIX timestamp for execution; https://www.reddit.com/r/ifttt/comments/ahypb7/universal_ingredients_for_all_services/ - support like upvotes or comments would help make it noticed.

[AlbertMN]

This version might fix it. Please try it :)

From what I've gathered, this only happens in one instance; when sleep or hibernate is executed, PC is woken up, the computerAction.txt file still exists (although it's hidden), so new files will simply replace this one without ACC picking it up properly. The code in the new version checks when the PC is opened again, and deletes all files in the action-check folder. This should prevent this from happening, unless you've experienced other fatal actions causing this @peter-moran.

When ACC starts, it clears the folder, so after shutdown, restart and logout (which all terminates all running software) upon login and startup of the ACC software, the action folder should be cleared, not resulting in this problem.

All non-fatal actions are deleted imediately - even before execution.

ACCsetup.zip

[Hutchby]

Hello! I've just discover ACC, so i tried the v1.2.1 and i have the same issue with sleep (Google assistant + Dropbox) ACC can't delete the file and the computer wakes up just after going to sleep.
So I try the new one and I still experienced the same issue on sleep command (fatal action in log).
I have a proposition for a quick fix, may be add a delay before sleep/hibernate? So the sync have enough time to finish, like 0,5sec? 1sec? user variable? Not the best solution but functional until a better one.

[AlbertMN]

The delay is indeed not a very good fix, as ACC has no way of knowing how many files Dropbox has to sync, how long it'll take or when it's done. I'd like to avoid having this as a "fix", but if I don't find any other fix soon, it could be a temporary one. I'll keep investigating.

[AlbertMN]

I've tried contacting the Google Assistant team to ask them to either fix their IFTTT {{TriggeredAt}} ingredient, or add more - without luck so far. I'll try again on Monday through their support website livechat system. I urge everyone to help making them aware of this issue. Will update this issue once I know more.

It still hasn't been possible to work out a fix for this in the software, and the dream scenario is still being able to call the files unique names.

[g2bb]

Any update on this issue or it's resolution? I'm still having the issue today.

[AlbertMN]

No news yet. Been super busy and haven't had much time to work on ACC. Will take a look this weekend.

[AlbertMN]

I've come to the conclusion with fellow developer and ACC-contributer Gamma1991, that there is no way to fix this issue IFTTT-wise, and probably not code-wise either at the moment.

I've tried to get in touch with the Google Assistant team (specifically the ones that do the IFTTT-service intergration), but without luck so far. I've also tried contacting the IFTTT team, as a potential fix for this - that would most likely benifit a lot of developers using IFTTT - could be a global "ingredient" (IFTTT's 'variables' for applets), called {{UnixTimestamp}}, allowing for unique filenames, which is what this project needs.

If you wanna help, you can try and tweet at "@ActionsOnGoogle", which is probably the closest we get to the Google Assistant team, or somehow contact an IFTTT-developer (< harder than you'd think)

Again, thanks for your patience... I really hope we find a good solution to this soon, but right now one hasn't presented itself just yet.

[AlbertMN]

One fix would be using "Filter code" in the IFTTT applets. However, to publish an applet with filter code (which would, as the image shows, allow me to create the file with a unique name, solving the problem) requires a paid IFTTT platform subscription, which ACC does not have. These plans are quite expensive, and made for big companies like Google - not open source projects. I'll try contact IFTTT and see if there's a chance filter code could be unlocked for the project, but I doubt it's gonna happen.

[AlbertMN]

I've thought of a potential fix that can be implemented in the software. Will test it the next few days - everyone who is experiencing this issue are very welcome in our Discord server, in the #testing channel, where I will be posting test builds that would require someone who experiences the issue (not me), to test it before I know if it works. Thanks.

[AlbertMN]

Here it is! Hope it fixes the issue (fingers crossed). Please test it and report back, that'd be very helpful.
ACCsetup.zip
(reuploaded 25/05/2019)

[peter-moran]

I can confirm this works. I sent the sleep command multiple times in a row, and each time it was able to work.

[AlbertMN]

Fantastic - thanks for confirming. Closing this issue - a new release with the fix will be out soon :)