Child Item

No errors in IFTTT applet log, but no file created in dropbox either

My IFTTT applets that create or appent to text files in dropbox have not been working reliably for months now. I was just looking at one applet's activity log and it shows that it has run dozens of times recently/today (10/13), but the last file it created in the target folder was on 10/6. Multiple of my applets have been behaving the same way. Some of them show errors in the applet's activity log, but many show that the applet ran successfully, despite no file being created. What the heck is going on? I keep submitting issues to IFTTT and dropbox and progress has only been made on the ones with errors (they told me that I might have a contention issue in some cases where the same trigger in multiple applets that create files was creating multiple files in dropbox in different folders at the same time, hence the error I was seeing). But what can I do about these no-error cases where files just don't get created?

Find more posts tagged with

Sync

Closed - Partially Delivered

Accepted answers

Rich

There really isn't anything that Dropbox can do to assist you. IFTTT would be the ones that created the interface between them and Dropbox, so only they can support it. Dropbox cannot provide support for third-party created apps or services.

If you had said that this just started happening, then I would suggest that it might be due to the Dropbox API v1 being shutdown recently (after being deprecated 15 months ago), and that any app or service that hadn't updated to use API v2 would fail to connect to Dropbox.

All comments

Rich

jrtinz

What does this mean:

"IFTTT, a Dropbox Premier Partner"

And then practically all posts regarding IFTTT say something like "Nothing we can do about it - contact IFTTT".

In troubleshooting issues where I work, it's always nice to get the guy who helps you out by saying "Nothing I can do, the problem is leaving here fine".

hepcat72

This has been an ongoing issue for months and it is as yet unresolved. I’ll give a little update here with the different behaviors I’ve observed and what I’ve tried:

1. Attempt: changed the file name in the IFTTT applet.

Result: the first time the applet was triggered, it created a file. Each subsequent triggering did not create a file.

Interesting note 1: the companion applet (for when the last person leaves) has the same file name structure but creates a file every time and the files have the string “ (#)” just before the extension.

Interesting note 2: when I duplicate a file in the Dropbox web interface, it has the same string format (with “ (#)”).

Interesting note 3: The applet is supposed to only run when the first person arrives, but it runs when each of us arrives home separately whereas the companion applet only runs once (when the last person leaves - as it’s supposed to).

2. Attempt: Changed the directory the file is supposed to be created in.

Result: same as above (#1)

3. Attempt: Edited the connection for both life360 and Dropbox on IFTTT.

Result: same as above (#1)

4. Attempt: created a separate applet that has the same trigger (life360 first person arrives home).

Result: It ran twice in the first 2 days when my wife got home and ever since has run reliably when I have arrived home. I usually arrive home first, so this seems normal. What’s not normal is that each time I arrive home, the applet is triggered twice. I get 2 notifications at the same time. I have received an email for each trigger event.

5. Attempt: created a separate applet that has the same action (create a text file in the same Dropbox folder) but a different trigger (regular lkfe360 location service)

Result: the applet will not trigger. The first time I edited the applet, the location appeared to have not saved, as it was a random location in CA (I’m in NJ). The second time I edited the applet, the location was correct when the page loaded and it changed a couple seconds later while i was looking at it to about 1.3 miles up the road to the north). Since then, the location has been correct, but it still has never triggered despite me coming and going numerous times.

Interesting note: I have another applet that uses the same trigger and same location, and it works reliably!?

So while typing this up, I cand up with a new hypothesis of what might possibly be happening. I think that something is wrong with the Life360 trigger. I’ll be each tI’ve I arrive home, it is causing 2 triggering events and when that happens, as was suggested with another of my Dropbox applets, there becomes a contention issue with creating the file... However that doesn’t explain why the first file gets created every time....

Mark

@jrtinz - the issue is that nobody at Dropbox can alter or change anything from a third party supplier. So, nobody can change what is happening with IFTTT.

hepcat72

Yeah, I get that. So they wrote the interface for the Dropbox service on IFTTT? I wasn’t sure who wrote the service code. I have been working with IFTTT support. Well, I’ve been submitting a lot of issues relating to dropbox. Let’s put it that way. And since someone else commented about IFTTT and Dropbox support here, I just thought I would give a little update as to my issue that I posted about initially.

Incidentally, has anyone else been complaining about this sort of issue?

Mark

I have to be honest and say I've not seen any other posts about IFTTT on here apart from this one.

The only other time I've seen it mentioned is people asking for recipes to use with it

jrtinz

I do understand the "3rd Party" difficulties. What I was getting at is that IFTTT claims to be a "Premier Partner" with Dropbox (https://www.dropbox.com/business/app-integrations/ifttt). That leads me to believe the API is a collaboration between the two. I am not so inclined to go troubleshooting myself in such cases.

Hepcat: I spent my entire career in engineering support. Whenever someone came to me with a problem description as detailed as yours, I made it a point to thank them for taking the time to provide it. So you have my appreciation because understanding your problem helps me to understand similar issue I have.

In any case - I have seen comments that Dropbox has removed "public" folders. And I've seen IFTTT queries asking why IFTTT only uses public folders on Dropbox. I'm not sure what the status is relative to this, if it's been addressed, or a brand-new issue. I'm just trying to develop on my end something that works. Judging by the uptrend in Dropbox/IFTTT receipes, a lot more topics on both sides are going to show up. Hopefully these topics will be of the "how-to" variety, and not fouled up and broken API between the two.

hepcat72

Hi Jrtinz,

Thanks. I have finally gotten a work-around up and running and just had my first successfully pair of triggering events. Basically, since the handling of file name conflicts is inconsistent, even among the same services (e.g. the triggers "Life360: first person arrives" and "Life360:last person leaves" handle file name conflicts differently - the former does not create a dropbox text file and the latter creates a dropbox text file with an added string to make its name unique), I added a step to my folder action to delete the file at the end of the script. Sure, that's probably how I should have done it in the beginning, but until recently, I didn't know the shell tricks to safely handle spaces in the path/file name.

Now I'm left with the initial issue, that caused me to have to deal with this behavior in the first place: IFTTT added a colon to its datetime string that I was using in the file names. This caused syncing and other file issues (e.g. I couldn't edit a file with a colon in its name in text edit). So I had taken out the datetime string from the file name and encountered this inconsistent file name conflict issue.

I have a number of files that the applet created that have colons in the name, as evident from the dropbox web interface and from doing `ls` on the command line. The Finder displays the file names with a forward slash in place of the colon.

I think I could probably figure out a way to safely handle these files programmatically, but the issue remains that certain apps (e.g. Text Edit) are buggy when it comes to handling files with colons in their name.