Document "CoapClient was reset" promise rejection about node-tradfri-client

[AlCalzone]

This can happen on any request/observation that has not completed yet when the user calls reset(). It's not a critical error but has to be there to notify the user that his request cannot be completed.

[neophob]

for reference, this error I captured:

Error: CoapClient was reset
    at normalizeReason (/myproject/node_modules/node-coap-client/build/lib/DeferredPromise.js:5:16)
    at Promise.rej [as reject] (/myproject/node_modules/node-coap-client/build/lib/DeferredPromise.js:13:36)
    at Function.reset (/myproject/node_modules/node-coap-client/build/CoapClient.js:191:33)
    at TradfriClient.reset (/myproject/node_modules/node-tradfri-client/build/tradfri-client.js:158:39)
    at tradfriClient.ping.catch.then (/myproject/app/lib/tradfriService.js:167:32)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)

To reproduce:

• make sure you can control your lights
• disconnect ethernet not tradfri gateway
• send 10 commands (for example turnOn) to the gateway
• wait a minute, then the error pops up

[neophob]

Another option would capture this rejected promise and use the error callback to signal an error

[AlCalzone]

The error pops up, because you call reset in your app:

at TradfriClient.reset (/myproject/node_modules/node-tradfri-client/build/tradfri-client.js:158:39)
at tradfriClient.ping.catch.then (/myproject/app/lib/tradfriService.js:167:32)

[neophob]

I know, it was just an idea, either update the docs that reset is an async function that returns a promise OR don't change the docs but use the error callback to signal the error.

[AlCalzone]

I'm leaning towards emitting a general library error and swallow the rejections. This means the corresponding documentation will have to state that all pending promises will neither be resolved or rejected anymore. Do you think this is good from a user's point of view?

Regarding your code snippet:
Are you catching rejections from ping? IMO that should always resolve and never reject. Or am I misunderstanding your stack frame?

[neophob]

I'm fine with swallowing the error and emitting an error - i think as long as the emitted error is understandable it should be fine and makes the implementation easier.

Yes I catch ping call, there was a rejection when I rebooted the gateway.

[AlCalzone]

Yes I catch ping call, there was a rejection when I rebooted the gateway.

DTLS timeout? If so, that's a bug since ping should handle the errors itself.

[AlCalzone]

"CoapClient was reset" should now be swallowed and transformed into an "error" event with a slightly more descriptive message.

[AlCalzone]

Released in v0.10.0