For example lets say you're subscribed to the order books channel, and someone creates an order, but then immediately deletes it. This is going to cause 2 messages back to back. If the application is trying to keep track of the order book, it might end up processing the delete before the create, which will result in an order being added to the local order book that shouldn't have been.
If the goal is to keep the websocket reader from blocking, a buffered chan should be used instead (though this might introduce different issues). However I think calling the handler synchronously is perfectly fine. If the consumer wants to implement a buffered chan, they can.
Websocket responses should not be launched in a goroutine (https://github.com/bitfinexcom/bitfinex-api-go/blob/master/v2/websocket_service.go#L269). This can cause race conditions if 2 messages for the same item come in at near the same time.
For example lets say you're subscribed to the order books channel, and someone creates an order, but then immediately deletes it. This is going to cause 2 messages back to back. If the application is trying to keep track of the order book, it might end up processing the delete before the create, which will result in an order being added to the local order book that shouldn't have been.
If the goal is to keep the websocket reader from blocking, a buffered chan should be used instead (though this might introduce different issues). However I think calling the handler synchronously is perfectly fine. If the consumer wants to implement a buffered chan, they can.