Feature request: easily track the result of peerSocket send

[Sergius]

I want to be resliient with the data I send from/to device and companion.

But there is no easy way of track if the message was sent in a lapse of time, because:

* The only communication we have is with callbacks, not promises.

* The error event is not connected to the 'send' action that originated the error, so we cannot easily track the missed messages.

My proposal is:

1. Upgrade the API to return Promise-like responses, instead of unconnected callbacks. This way we can rely on the platform to let us know wether it went ok or not.

2. At least provide the original `data` property of the original `send` action. This will help us to construct the 1. option I just wrote, without creating a complex system of messaging and tracking IDs between both device and companion (that is posible and already done, but too much!).

What do you think?

[adiroiban]

My understanding is the the Messaging API provides UDP style communication, while File-Transfer style provide TCP style 🙂

If you want to make sure data is received, use the File-Transfer API.

Have you ever received an error event for a message lost in transmission?

As long as it is possible to create a "complex system of messaging and tracking IDs", I don't think that Fitbit will put resources in improving this.

Getting Promoses based API would be nice... but the communication between the device and the phone is still miserable ... so I would prefer to get a reliable phone to device communication first 🙂

[harry6789]

I independently ran into this issue and agree that it's a problem.

I'll add that it doesn't look like the only documented error (BUFFER_FULL) is implemented correctly. When you fill up the buffer by sending a load of messages quickly, you will not see a BUFFER_FULL error event, but instead your app will crash with the error: "Error 12 Critical glue error". Test code for this here: https://gist.github.com/harryeakins/9a5ce6168a474b0849772d475627b3f8