When a RemoteCommandRequest has an OperationContext member, that member is only accessed on the thread that calls scheduleRemoteCommand/NetworkInterface::startCommand. The general historical rule (see this comment) is that the client-thread owning the OperationContext should be the one to call scheduleRemoteCommand, to ensure that the OperationContext is not destroyed before it is read off the RemoteCommandRequest.

Generally, it is not safe to call scheduleRemoteCommand with an RCR with an OperationContext from a different thread, unless there is additional synchronization that ensures the OperationContext isn't destroyed.

We should consider enforcing these rules in code, i.e. by insisting that the thread-local client of the thread calling scheduleRemoteCommand owns the OperationContext, etc.