Intermittent pong messages leading to failure in test cases

I have a citrus test case which uses Websockets cleint for testing. It sends some request and validates the response (JSON).

_Premise:_

- I encountered that whenever there is a Ping-Pong communication between the client and server, citrus logs the incoming pong as "received pong message"
- The receive template logs an error as it can not convert the "java.nio.HeapByteBuffer" into JSON.
- This was leading to the failure. However, I referred to a previous discussion in another github citrus thread, (**_Websocket : 'received pong message' : Failed to convert value of type 'java.nio.HeapByteBuffer' to required type 'java.lang.String' #284_**) and was able to only partially solve the issue by updating the citrus version to 2.8.0 from 2.7.0, as was suggested there.

Now I still face this "received pong message" intermittently, that is leading to failure.
However, if it's something like "received text message", the cases work fine.
An exception occurs only if "received pong message" is received and it is being received intermittently.
Like for example, the same websocket call sometimes returns a "received pong message", that leads to failure and at other times return a "received text message", for the same request, which works fine.

_Questions:_

1. Why is the same websocket call with same message body, sometimes flagged as "received pong message" and sometimes as, "received text message" in the response?
2. How can I control the ping/pong behavior from Citrus?
3. If I can not how can I filter a pong response from test response?

_**Below are the logs that logs the websocket response as "received text message"**_

12:39:52,888 INFO container.Template| Template was executed successfully
12:39:52,888 INFO port.LoggingReporter|
12:39:52,888 DEBUG port.LoggingReporter| TEST STEP 19/90 SUCCESS
12:39:52,888 INFO port.LoggingReporter|
12:39:52,888 DEBUG port.LoggingReporter| TEST STEP 20/90: receive
12:39:52,888 INFO nt.WebSocketConsumer| Waiting 100000 ms for Web Socket message ...
12:39:52,888 DEBUG nt.WebSocketConsumer| Waiting for message on 'ws://some-websocket-server-url:60000' - retrying in 500 ms
12:39:53,388 DEBUG nt.WebSocketConsumer| Waiting for message on 'ws://some-websocket-server-url:60000' - retrying in 500 ms
12:39:53,888 DEBUG nt.WebSocketConsumer| Waiting for message on 'ws://some-websocket-server-url:60000' - retrying in 500 ms
12:39:54,389 DEBUG nt.WebSocketConsumer| Waiting for message on 'ws://some-websocket-server-url:60000' - retrying in 500 ms
12:39:54,889 DEBUG nt.WebSocketConsumer| Waiting for message on 'ws://some-websocket-server-url:60000' - retrying in 500 ms
12:39:55,389 DEBUG nt.WebSocketConsumer| Waiting for message on 'ws://some-websocket-server-url:60000' - retrying in 500 ms
12:39:55,798 DEBUG trusWebSocketHandler| WebSocket endpoint (some_client_ip:41814->some_server_ip:60000) received text message
12:39:55,890 INFO nt.WebSocketConsumer| Received Web Socket message

_**Below are the logs that logs the same websocket response as above as "received pong message"**_

13:51:32,642 INFO container.Template| Template was executed successfully
13:51:32,642 INFO port.LoggingReporter|
13:51:32,642 DEBUG port.LoggingReporter| TEST STEP 19/90 SUCCESS
13:51:32,642 INFO port.LoggingReporter|
13:51:32,642 DEBUG port.LoggingReporter| TEST STEP 20/90: receive
13:51:32,642 INFO nt.WebSocketConsumer| Waiting 100000 ms for Web Socket message ...
13:51:32,642 DEBUG nt.WebSocketConsumer| Waiting for message on 'ws://some-websocket-server-url:60000' - retrying in 500 ms
13:51:33,142 DEBUG nt.WebSocketConsumer| Waiting for message on 'ws://some-websocket-server-url:60000' - retrying in 500 ms
13:51:33,643 DEBUG nt.WebSocketConsumer| Waiting for message on 'ws://some-websocket-server-url:60000' - retrying in 500 ms
13:51:33,741 DEBUG trusWebSocketHandler| WebSocket endpoint (some_client_ip:48860->some_server_ip:60000) received pong message
13:51:34,143 INFO nt.WebSocketConsumer| Received Web Socket message
13:51:34,143 DEBUG Logger.Message_IN| WEBSOCKETMESSAGE [id: 6be6c5df-9803-4b9a-be78-e2d54ff75585, payload: ][headers: {citrus_message_id=6be6c5df-9803-4b9a-be78-e2d54ff75585, citrus_message_timestamp=1618408294143, citrus_websocket_is_last=true}]
13:51:34,147 DEBUG citrus.TestCase| Entering finally block in test case

This second case as implied is leading to some exception that moves control to the finally block, ignoring rest test cases.