[enhancement]: Should we allow setTimeout in unload?

[Apollon77]

No existing issues.

• [X] There is no existing issue for my request.

Description

Currently we decline "adapter.setTimeout()" as soon as the stop process was started which completely prevents usage of setTimeout in unload. For some adapters, especially with custom "stopTimeout" in config this might be not the ideal way.

We could in general allow it - but need to be careful, but in fact will be cancelled anyway.

Wen could also allow it when a custom stopTimeout is set and only allow it then?

Why?

Matter adapter cleans up things and some use timeouts in the background (that are all inside the stopTimeout range)

How?

No response

[mcm1957]

Currently timers, intervals registered via this.setXxxx etc. are stopped BEFORE the onUnload callback is triggered - at least if I read the code correctly. (https://github.com/ioBroker/ioBroker.js-controller/blob/bfa740bb2b49095997c5b2bbc7adb8aabea851a1/packages/adapter/src/lib/adapter/adapter.ts#L2236)

Wouldn't it be a clean solution to call onUnload FIRST and do the cleanup of timers etc after returning form onUnload (or better during callback of onUnload?) This would possibly allow to remove blocking but still will ensure that all timers are canceled.

[mcm1957]

A shorthand workaround for matter could be to use setTimout (without "this") as such timers are not blocked but need special care that they are really cancelled.

[foxriver76]

Did we have reasons to already prevent it at this time? I think back then it was a known limitation that it cannot be used in unload handler. Basically it should also be fine to stop them after unload in general or do you expect any side effects @Apollon77?

[mcm1957]

I do not know the history. But in my oppinion the only goal is that all timers, intervals, ... are cleared before the adapter code is finally stopped.

[foxriver76]

we decided o stick to the current behavior