We use retoolRPC and occasionally there are socket hang ups and other network issues that trigger the default error logging behaviour in the polling listen method.
This is fine, however it does make for some messy logging situations. The actual reason for the failure is included so we could filter on these messages. But one other way would be to allow users the ability to decide what they want to do on an error instead. This shouldn't interfere with the operation of anything out of the box or by default, but it does give the consumer of the SDK the ability to back-off at their discretion, or to just propagate a failure and exit.
I also added package-lock.json to the .gitignore file because you guys use yarn.
We use retoolRPC and occasionally there are socket hang ups and other network issues that trigger the default error logging behaviour in the polling listen method.
This is fine, however it does make for some messy logging situations. The actual reason for the failure is included so we could filter on these messages. But one other way would be to allow users the ability to decide what they want to do on an error instead. This shouldn't interfere with the operation of anything out of the box or by default, but it does give the consumer of the SDK the ability to back-off at their discretion, or to just propagate a failure and exit.
I also added
package-lock.jsonto the.gitignorefile because you guys use yarn.