Thing status changes from REMOVING to INITIALIZING

[kaikreuzer]

I have observes a status transition that is not allowed according to the specification:

15:49:16.877 INFO  s.e.ThingStatusInfoChangedEvent[:43] - 'ntp:ntp:local' changed from REMOVING to INITIALIZING

This situation happens if a Thing is in REMOVAL status and a thing handler is registered for it.
Easy to reproduce:

• create a Thing
• stop the binding bundle
• delete the Thing -> it goes into REMOVAL
• start the binding bundle again

I would actually expect, that the handleRemoval() method is called on the handler in this situation.

[J-N-K]

I did have a look at this one. The problem is that the ThingManager.thingRemoving sets the ThingStatus to REMOVING and notifies the handler about that. The handler then sets the ThingStatus to REMOVED (at least the BaseThingHandler) and the ThingManager then removes the thing.
Obviously waiting for the handler to update the ThingStatus will fail if the handler is missing.
I'll add a check if the ThingStatusDetail is HANDLER_MISSING and update the ThingStatus to REMOVED instead of REMOVING. This should solve the problem.

[kaikreuzer]

@J-N-K wrote:

If we need an initialized thing handler to go from REMOVING to REMOVED (otherwise dispose may fail, if communication with the device is needed), then how should a thing with HANDLER_MISSING be removed if not by initialization first?

Well, as I stated in the issue: "I would actually expect, that the handleRemoval() method is called on the handler in this situation." - which would mean that we would have to clearly document that this method can be called on an uninitialized handler as well.

Alternatively, the framework might call initialize(), but must not set the status to INITIALIZING, when it is already REMOVING.

The 3rd option is to change the specification to actually ALLOW the transition from REMOVING->INITIALIZING (imho not a good one).

[J-N-K]

IMO neither the first nor the second option solve the problem. Things that need some sort of de-coupling probably need a handler that is ready to communicate with the thing, i.e. the thing needs to go all the way to ONLINE status before handleRemoval can properly do its job.

[kaikreuzer]

The responsibility is with the handler. If it requires a connection, it can establish it, nobody says that this wouldn't be allowed. In 95% of all bindings, no action is required anyhow, so for them it wouldn't be relevant in any case.

[sjsf]

I would clearly prefer the second option:

Alternatively, the framework might call initialize(), but must not set the status to INITIALIZING, when it is already REMOVING.

As you already said: a handler with a working connection to the thing is required. ThingHandler.initialize() does exactly that: it does whatever is required in order to be able to communicate with the device.

Setting the thing status on the Thing object in fact is never done by the handler itself, but always by the framework, although it might feel different because BaseThingHandler.setStatus(...) is used. This hover always goes via the ThingHandlerCallback back into the ThingManager. Here we can easily handle this alternate path. And as I already said in the linked PR: We of course can indicate nicely that we are initializing the handler for this very purpose by using a dedicated, new status/detail combination, like e.g. INITIALIZING/FOR_REMOVAL or REMOVING/INITIALIZING or similar.

I any case, this burden should be put onto the framework, not the handler! I would really like to not make the handler implementation any more complicated than it really needs to be.

[ivivanov-bg]

One more thing that needs to be taken into account - it is possible while the handler waits for the end user to do some interaction with the device - the framework do be restarted (while the thing is still in REMOVING state). What would then be the behavior of the thing handler after the restart?