DropBox node not responding to new file in DropBox

General
1

Hi all,

Before opening an issue, I'd request for advice regarding any logging or monitoring means, to allow a better issue description and issue reproduction.

What is happening: I have a DropBox node watching for any new files. After some time (days to weeks) the node does not react to file changes anymore. The only way to re-active it is to change a node property (eg. the Name property). Then, it initializes and workes again as expected.

Any hints or shall I open an issue?
Thanks, Damos

2

Anyone?

I've also opened an issue #260 on GitHub, but it looks pretty quiet there.

Please help, the whole flow became unreliable.

Thanks,
Damos

3

You might want to add a catch node connected to a debug node (set to display the complete msg object) to see if anything shows up.

4

Thanks, @zenofmud, will do.

I had a status node connected to it, but nothing came back. It's like the node was "sleeping".

I'll check and come back.

5

As I speak, files are coming to Dropbox and the node is not reacting.
I just re-deployed the flow and now it's working.

This is really annoying. I even created a new access token on the Dropbox developer platform, no success.

Can anybody help, please? Is the developer of the node maybe listening? Who could this be?

Thanks,
Damos

6

Hi Damos,

The node is one we inherited in the project from other developers who contributed it but have long since moved on.

I have done occasional fixes in the past with it, but as it isn't a node I use, it isn't one I can easily dive into.

This is true of a lot of the nodes in the same web-nodes repository in GitHub.

I may be able to take a look at it this weekend, but I can't promise it.

1 Like
7

That would be fantastic, Nick!
Tell me if I can help in any way.

8

I just had a look into the dropbox code (assuming it is that one: https://github.com/node-red/node-red-web-nodes/blob/master/dropbox/dropbox.js) and discovered that it outputs trace messages if trace is on.
So, I'll switch trace on an have a look as well.

Having said this, my developing activities halted a decade ago so I didn't want to go out on a limb :wink:

9

Nick, based on the log I discovered some strange behavior. Let me do some tests, maybe my findings can help you narrow down the potential bug.

One question: would

node-red-node-dropbox
Node-RED nodes to watch and download files from Dropbox
 1.0.2 2 years, 5 months ago

and

node-red-node-web-nodes
A collection of Node-RED nodes for popular web services.
0.3.2 5 years, 5 months ago

be the same?
I'm working with the first.

10

@knolleary, here's what I have so far:

I have two Dropbox nodes, one watching the "camera" directory the other the "backup" directory. I restarted both nodes and watched the log:

# tail -F messages -s 30 | grep dropbox
Apr 27 11:26:19 ccu3-webui daemon.debug node-red[1111]: [dropbox in:Dropbox camera directory] draining files emit=false
Apr 27 11:26:19 ccu3-webui daemon.debug node-red[1111]: [dropbox in:Dropbox backup directory] draining files emit=false
Apr 27 11:26:19 ccu3-webui daemon.debug node-red[1111]: [dropbox in:Dropbox camera directory] polling backoff=0
Apr 27 11:26:20 ccu3-webui daemon.debug node-red[1111]: [dropbox in:Dropbox backup directory] polling backoff=0
Apr 27 11:26:59 ccu3-webui daemon.debug node-red[1111]: [dropbox in:Dropbox camera directory] polling backoff=0
Apr 27 11:27:13 ccu3-webui daemon.debug node-red[1111]: [dropbox in:Dropbox backup directory] polling backoff=0
Apr 27 11:27:45 ccu3-webui daemon.debug node-red[1111]: [dropbox in:Dropbox camera directory] polling backoff=0
Apr 27 11:27:58 ccu3-webui daemon.debug node-red[1111]: [dropbox in:Dropbox backup directory] polling backoff=0
Apr 27 11:28:35 ccu3-webui daemon.debug node-red[1111]: [dropbox in:Dropbox backup directory] polling backoff=0
...
...
Apr 27 18:16:33 ccu3-webui daemon.debug node-red[1111]: [dropbox in:Dropbox camera directory] polling backoff=0
Apr 27 18:16:57 ccu3-webui daemon.debug node-red[1111]: [dropbox in:Dropbox backup directory] polling backoff=0
Apr 27 18:17:12 ccu3-webui daemon.debug node-red[1111]: [dropbox in:Dropbox camera directory] polling backoff=0
Apr 27 18:17:52 ccu3-webui daemon.debug node-red[1111]: [dropbox in:Dropbox backup directory] polling backoff=0
Apr 27 18:18:17 ccu3-webui daemon.debug node-red[1111]: [dropbox in:Dropbox backup directory] Error polling:Error: getaddrinfo EAI_AGAIN notify.dropboxapi.com notify.dropbox api.com:443
Apr 27 18:19:28 ccu3-webui daemon.debug node-red[1111]: [dropbox in:Dropbox camera directory] Error polling:Error: connect ETIMEDOUT 162.125.19.131:443

After the two errors at 18:18 and 18:19, both nodes stopped any activity. The catch node (as suggested by @zenofmud) didn't throw any error.

Productive environment: node-red v1.0.5, running on the Homematic home automation platform (Linux) as Redmatic.
For the sake of reproducing the node's misbehavior, I ran the same scenario in parallel (node-red v1.0.6 on Windows on a local PC), polling the same Dropbox directories. Here I couldn't identify any anomalies so far, which is strange.

Node-red was thankfully ported to Homematic by @hobbyquaker, so I'm involving him. @Sebastian, maybe you can suggest something.

Thanks and tell me if I can support.

11

This issues still exists. I have to restart the DropBox node at least once a day.

Anyone?

12

Sorry @DamianosS, I completely forgot to come back to this. I won't have time to investigate until later this week.

13

Sure, Nick, thanks. As long as you will have a look. Until then I'll re-initialize the node.
I can't do that programmatically, can I?

14

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.