There's a race condition in CommandAwareRpcDispatcher, as we do staggered gets. When the RspList is prepared, and then in processCallsStaggered$lambda the Rsp is filled in - both of them can set is as received but later see that the other response was not received yet, because there's no memory barrieri n between the setValue/setException and checking wasReceived.

The race above happens when two responses come but none of them is accepted by the filter, but there's a second one in JGroupsTransport when the first response is accepted but then comes another one. In JGroupsTransport.invokeRemotelyAsync in the lambda handling rspListFuture.thenApply we may see another thread concurrently modifying the rsps; e.g. in checkRsp you find out that the concurrently written response was received and it's not an exception according to flags, but the value will be null, so you return null while you can have valid response in the other Rsp.