There is an edge case in which the request/responses send to and from the binary port can get out of sync. For example: sidecar sends request #1, the response is not consumed but it stays in the buffer, then sidecar sends request #2 but gets the response for request #1. This issue will not sort itself out and requires restart of the sidecar. Usually this results in unexpected payload variant received error message, but if the subsequent requests are of the same type this will go unnoticed and could lead to serious misinformation. The root cause is being investigated, but regardless of it, we'll extend the binary port communication protocol to use the request ID.
There is an edge case in which the request/responses send to and from the binary port can get out of sync. For example: sidecar sends request #1, the response is not consumed but it stays in the buffer, then sidecar sends request #2 but gets the response for request #1. This issue will not sort itself out and requires restart of the sidecar. Usually this results in unexpected payload variant received error message, but if the subsequent requests are of the same type this will go unnoticed and could lead to serious misinformation. The root cause is being investigated, but regardless of it, we'll extend the binary port communication protocol to use the request ID.