Data coherency between Trigger and Action(s)

This sorta goes back to the discussions about knowing what event caused an action to be executed.

Say there's a defined event that gets triggered due to a state change in a plugin device. And that this particular device updates rapidly (possibly multiple times per second). And that the trigger for this event causes an Action for the same plugin to be called, with the same device as a parameter.

Now, as I understand it, this plugin has at least two threads running. One is executing runConcurrentThread(), another is running all the methods as called by the Indigo server. Both of these threads can access the same (?) device object. Not really the same one, as each gets a read-only copy of the object which it can refresh (server->plugin) or update (plugin->server) as needed.

Now, for the plugin to work properly, the Action that was called needs an identical copy of the device object as it existed when the Trigger was executed. Is this guaranteed? The plugin code is calling indigo.trigger.execute(trigger) from the same thread that is processing the incoming data and updating the states, so that should be safe. But what happens after the trigger is queued up on the server? Is that action processed, and the device object parameter copied, before the indigo.trigger.execute() call returns? Because the device state could change very soon after the plugin code is resumed.

Am I worried about nothing?

[matt (support)]

The plugin code is calling indigo.trigger.execute(trigger) from the same thread that is processing the incoming data and updating the states, so that should be safe. But what happens after the trigger is queued up on the server? Is that action processed, and the device object parameter copied, before the indigo.trigger.execute() call returns? Because the device state could change very soon after the plugin code is resumed.

I glanced at your plugin code, and I assume you are referring to the brokerDevice argument in the action callbacks like publishDeviceAction here. So your question is will that device instance have the same attributes/states as the one that is passed into triggerCheck (argument device) which is causing the action to be executed via the indigo.trigger.execute(trigger) call?

Unfortunately, I don't think that is guaranteed. The Indigo Server will send its current device instance "snapshot" when it calls the action, which might be newer than the one passed to the triggerCheck() method that kicked off the sequence of events.

In practice, I'm not sure if this will be an issue or not. It'll depend on how quickly the device updates are occurring and how busy the Indigo Server is. The processing on the Indigo Server side (the indigo.trigger.execute() call) should be very fast unless the server is really getting behind on plugin API requests.

I think the ideal solution here is that triggerCheck would inspect the trigger action and if it is one that belongs to the plugin it would just directly call the function itself so that it could pass in the device argument. The problem with this is the Indigo Object Model doesn't yet give you access to the action. However, that is getting to be pretty high on my priority list, so it may not be a problem for too much longer. Other issue though that I just thought of is the trigger action is actually a list of actions. So the action that feeds back into the plugin might not be the only one, in which case things start to get complicated. Another complication on this approach would be if the action has a delay associated with it. We might be getting into pretty extreme edge cases here though.

The only alternative to this is for the action logic (and UI) that the user might want to be mirrored down into the trigger level. I don't know how painful that might be (both on the dev side and the bloat on the UI for the usability side).

Or maybe in practice this really isn't an issue. If it is, you might be able to avoid the problem by adding a delay after whenever your plugin calls indigo.trigger.execute() to have it block the incoming MQTT processing for a second just to try to force the device to not be changed.

Or maybe in practice this really isn't an issue. If it is, you might be able to avoid the problem by adding a delay after whenever your plugin calls indigo.trigger.execute() to have it block the incoming MQTT processing for a second just to try to force the device to not be changed.

I could do that, or implement a lock of some sort. I don't suppose there's any way to know when all actions tied to a trigger are complete?

Or maybe we'll just wait and see if it every becomes an issue.

[matt (support)]

I could do that, or implement a lock of some sort. I don't suppose there's any way to know when all actions tied to a trigger are complete?

Afraid not.

Or maybe we'll just wait and see if it every becomes an issue.

Recommended.