Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[enhancement]: Should we allow setTimeout in unload? #2978

Closed
1 task done
Apollon77 opened this issue Nov 28, 2024 · 5 comments
Closed
1 task done

[enhancement]: Should we allow setTimeout in unload? #2978

Apollon77 opened this issue Nov 28, 2024 · 5 comments
Labels
enhancement ⬆️ refinement 🔍 Needs refinement with core developers wontfix

Comments

@Apollon77
Copy link
Collaborator

No existing issues.

  • 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
Copy link
Contributor

mcm1957 commented Nov 28, 2024

Currently timers, intervals registered via this.setXxxx etc. are stopped BEFORE the onUnload callback is triggered - at least if I read the code correctly. (

const finishUnload = async (): Promise<void> => {
)

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
Copy link
Contributor

mcm1957 commented Nov 28, 2024

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
Copy link
Collaborator

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
Copy link
Contributor

mcm1957 commented Nov 30, 2024

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 foxriver76 added refinement 🔍 Needs refinement with core developers wontfix labels Dec 2, 2024
@foxriver76
Copy link
Collaborator

we decided o stick to the current behavior

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement ⬆️ refinement 🔍 Needs refinement with core developers wontfix
Projects
None yet
Development

No branches or pull requests

3 participants