Resume timer on deploy/restart not working in subflow

[tobi-bo]

Hi, I like this node very much, great work!

But I'm facing an issue, when putting the node inside a subflow. The "Resume timer" option does not work then. It seems to me, that the stored file cannot be matched to the right instance of the node after the redeploy. Because when I restart the flow manually after a redeploy a second file appears with a different id.

Here is a sample flow, which shows the issue:

[{"id":"9728e4e4.7cbf18","type":"subflow","name":"Subflow 1","info":"","in":[{"x":60,"y":100,"wires":[{"id":"f042275d.44a548"}]}],"out":[{"x":380,"y":60,"wires":[{"id":"f042275d.44a548","port":0}]}],"status":{"x":380,"y":140,"wires":[{"id":"f042275d.44a548","port":2}]}},{"id":"f042275d.44a548","type":"stoptimer-varidelay","z":"9728e4e4.7cbf18","duration":"30","durationType":"num","units":"Second","payloadtype":"num","payloadval":"0","name":"","reporting":"every_second","persist":true,"x":210,"y":100,"wires":[[],[],[]]},{"id":"e6e5e306.32d9f","type":"inject","z":"691e6cd7.2ae934","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"Hello","payloadType":"str","x":130,"y":100,"wires":[["31f1f0bd.9e8398"]]},{"id":"48439cbd.542934","type":"debug","z":"691e6cd7.2ae934","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":460,"y":100,"wires":[]},{"id":"31f1f0bd.9e8398","type":"subflow:9728e4e4.7cbf18","z":"691e6cd7.2ae934","name":"","env":[],"x":290,"y":100,"wires":[["48439cbd.542934"]]}]

[hamsando]

I hope to have a chance to investigate this over the weekend.

[hamsando]

The way the "resume" works is to store the data necessary to resume in a file, with the filename being the node.id of the node in question. This works well on non-subflow nodes, as once assigned, these keep their node.id.

However for nodes in a subflow, that seems to not be the case. It appears that the subflow is instantiated with the contained nodes having a different id each time. This makes it challenging to store data in some manner that the node can find as the node.id is no longer constant.

I'm still thinking about what other possibilities there may be, but (1) it may not be feasible and (2) if it is feasible, it will likely take quite some time.

[hamsando]

Almost immediately after writing my previous comment I had an idea - and after a quick bit of testing I think I've figured a simple way around this. I'll need to do some more testing to be sure - but I should be able to push out an update in the next few days.

[hamsando]

Fixed in 0.5.0.

Unfortunately one side effect is that any 'legacy' files that remain in the folder for the timers in the subflow, are orphaned and can't be automatically deleted. You can delete them manually.

[tobi-bo]

Wow! Very fast response! Really appreciate your work. I thought about that issue the last days, too, when reading your thoughts here ;-) As I see, you solved it, by concatenating the node ids of the subflow node and the timer node. I had a similar idea and it works good, when one put the timer node in a subflow which is directly called from a main flow. In fact, in my setup I have subflows that call other subflows that again have timer nodes. With this constellation there is still the problem, that the subflow node, which is placed in another subflow, changes its id during a redeploy. Maybe you can investigate to generate a filename which contains all ids of the subflow chain to solve it. I like this feature very much, so it would be great, if you can look into it again.

[hamsando]

Closing this issue as fixed in 0.5.0 based on the premise that resuming the timer in subflows was broken and has been fixed. Opened Issue #11 to track the problem of resume timers in subflows, within subflows.