Potentially insufficient error handling for emitEvent()

[jak0bw]

Related to #237 but on the sender side.

When emitting an event §8.27 The emitEvent() method does only define a SecurityError and a NotFoundError, but does not define an error if the emit fails due to another, perhaps technical problem. Consider similar to #237 a sender who wants to emit an event to the configured, but currently offline mqtt broker. This probably results in an error on the protocol level, but is never communicated to the application level. EmitEvent() probably needs a similar definition as:

§7.13 The invokeAction() method
8. If the request fails locally or returns an error over the network, reject promise with the error received from the Protocol Bindings and abort these steps.

[zolkis]

The PR #264 is not fixing the issue. Discussion summary from the Scripting call on 28.9.2020.
The problem has many sides:

1. The ExposedThing implemention script should get an error when a notification fails (that is, local delivery). This should be standardized. I can make another PR for this.
2. If there is protocol (binding) support for conveying a subscription error to the clients, then it could be signaled at the clients through the ErrorListener callback. This could be implementation specific, until the TD spec defines a generic error mechanism for this.
3. The TD could define the errors to be signaled when interactions fail, or it could define specific interactions to handle error states (e.g. properties or actions or events). So, it's not standardized in the TD spec, but errors are considered to be business logic, to be defined in the TDs.
4. There was a point about handling errors at the client side for subscriptions (both via Promise and the error callback). This needs to be clarified more.

@egekorkan, @sebastiankb, @mjkoster please advise.

[zolkis]

1. The ExposedThing implemention script should get an error when a notification fails (that is, local delivery). This should be standardized. I can make another PR for this.

The proposed solution for this one would be to return a Promise by emitEvent(), which might reject with an error when the event notification is not successful. This is a trivial change.

2. If there is protocol (binding) support for conveying a subscription error to the clients, then it could be signaled at the clients through the ErrorListener callback.

For this one the Scripting API already has coverage via ErrorListener, though the exact mechanism is encapsulated by implementations and might differ binding from binding.

4. There was a point about handling errors at the client side for subscriptions (both via Promise and the error callback).

This is still outstanding and could be discussed in a separate issue. One (quite trivial) solution would be to revert to the separate subscribe()-unsubscribe() and observe()-unobserve() pair, which also align better with the TD spec. On subscription, a subscription id could be returned to ease subscription management.

[danielpeintner]

see #269

[danielpeintner]

Scripting Call 2020-10-19.
Closing...

TD related issue "defining error"

[relu91]

Open point:

The TD could define the errors to be signaled when interactions fail, or it could define specific interactions to handle error states (e.g. properties or actions or events). So, it's not standardized in the TD spec, but errors are considered to be business logic, to be defined in the TDs.

I am closing this one, the issue was solved and the last open point it is being tracked on the following issues:

• Error conditions for form requests wot-thing-description#303
• Allow array for response in From class? wot-thing-description#617
• Error Handling #200
• Define error responses wot-discovery#44
• Describe error response format for directory API wot-discovery#52 (related PR from the discovery task force)