What should happen if writemultipleproperties partially fails?

[benfrancis]

An issue which came up when implementing the writemultipleproperties operation from the Core Profile protocol binding in WebThings Gateway is what should happen in the case where the operation only partially succeeds (i.e. some properties are set successfully, but others aren't).

An obvious answer is that the whole operation should be treated as atomic and the other writes should be rolled back. But then what happens if the rollback fails and the Thing is still left in an in-between state? Is it possible that not all property writes are reversible? Another alternative would be to include information in the error message about which properties failed to write (following the Problem Details format).

We could do with some more precise assertions around error handling to define what responses a Thing should provide to a Consumer in this edge case and what (if anything) it should try to do to recover.

[egekorkan]

A bit of a tangential comment:

In another TF or GH Repo (could be Scripting API or TD so please help @relu91 , @danielpeintner ) we had discussed defining WoT specific error types that can transcend protocol errors. These could be used in the scripting API where the script-level (written by the developer) is unaware of the underlying protocol and can give the developer/user errors that can be mapped to actual protocol errors if needed. For example, the developer/user can get NotAuthorized which can be coming from HTTP 401 or MQTT 0x4 (https://www.vtscada.com/help/Content/D_Tags/D_MQTT_ErrMsg.htm). These can be also used for non-error cases. For meta operations, we can say that an object with the affordance name: error type can be then used.

If we decide to do something like this, I would propose to do it in the next charter though :)

[danielpeintner]

we had discussed defining WoT specific error types that can transcend protocol errors. These could be used in the scripting API where the script-level (written by the developer) is unaware of the underlying protocol and can give the developer/user errors that can be mapped to actual protocol errors if needed.

@egekorkan not sure if you mean w3c/wot-scripting-api#200 (comment) ?

w.r.t. the writemultipleproperties partially fails issue..

In Scripting we discussed a related topic. A runtime could theoretically offer writemultipleproperties forms (by doing it internally, wrapping multiple single writeProperty() calls into a Promise.all etc) even if the binding does not offer it. We decided against it (see w3c/wot-scripting-api#219 (comment)). Hence, either the binding reports success or failure.

The problem @benfrancis is having is how the binding (e.g., HTTP) can communicate any failures. I see the issue if parts of the property are not properly written. On the other hand, I see also complexity in conveying the information "what" succeeded and "what" failed.

[relu91]

An obvious answer is that the whole operation should be treated as atomic and the other writes should be rolled back. But then what happens if the rollback fails and the Thing is still left in an in-between state? Is it possible that not all property writes are reversible? Another alternative would be to include information in the error message about which properties failed to write (following the Problem Details format).

The problem @benfrancis is having is how the binding (e.g., HTTP) can communicate any failures. I see the issue if parts of the property are not properly written. On the other hand, I see also complexity in conveying the information "what" succeeded and "what" failed.

Indeed, I would support a transaction-based behavior with rollbacks if something went wrong. However, given the fact that we are dealing with physical devices, I'm not sure if you can always revert to the previous state if something is off.

[sebastiankb]

I don't have a good proposal, but I know that for Modbus there is a function called "Write Multiple Registers". Maybe there is something we can adopt?