Applications pending approval will return a different response body than what is presently supported.
Below is a copy of the actual response that comes back in this scenario:
```
{"status":401,"rateLimitTimeout":null,"body":{"request":"/1.1/statuses/update.json","error":"Read-only application cannot POST."}}
```
Whereas the current implementation assumes the presence of an `errors` array, reading off the first element (i.e. `result.body.errors[0]`), the above scenario throws an exception as `result.body.errors` is now `undefined` and cannot be indexed).
The proposed update seeks to account for this while retaining existing functionality and has been tested (error message in debug now properly says "Read-only application cannot POST."
Pushbullet dev here. Around 36 hours ago we started receiving around 750 additional requests per second to connect to our stream server. I blocked around 50 - 100 IP addresses to mitigate the spam. This spam traffic has continued unchanged since then.
I don't know for sure what caused this, but one user came forward reporting issues with their Node-Red setup after I banned the IPs (status code is my banned IP status code which is pretty compelling evidence). I can't be sure what is causing the issue since no User-Agent is included in the requests, but it for sure is at least partly Node-Red API users. I'd like to work on mitigating this since mitigating the spam traffic costs money.
My first theory here is in this PR. I am not aware of any guarantees that you'll never get multiple 'error' events, so it makes sense to clear the timeout before setting a new one to reconnect. Even if it is just defensive, it may not have much cost? If you do get multiple error events without this change, it is possible to trigger many connect() requests which can error out and then trigger many more connect() requests with lots of timeouts, which is not good.
Another thing to consider is that this library's dependency for PB (https://github.com/alexwhitman/node-pushbullet-api) already has code to reconnect if a websocket connection is lost without having been properly closed. I think an even better solution is verifying this works and then deleting the reconnect logic from here.
I'm not an expert on Node-Red though so I am only trying to offer suggestions to ensure everyone is a good citizen when using our API :) Thanks!
* On error throw a catchable
Throws an catchable exception if there is any error in sending the message. So you can react to it with a catch node
* Updated errorhandling
Updated the error handling process to be in compliance with the Node-RED Api
Dave Conway-Jones
Dave Conway-Jones
Andreas Martens
Matt Borja
Nick O'Leary
guzba
Frakke0
Vincent Hou
juggledad
JsBergbau
dxdc