Replication only allows one in-flight replSetUpdatePosition request to be sent to the upstream at a time. This is initially because when chaining is enabled, we want to avoid a flood of forwarded replSetUpdatePosition messages. However this means that we could necessarily delay the reporting of our own opTime changes.

For example, on secondaries after applying each batch, we update the lastApplied opTime and asynchronously flush the journal and update the lastDurable opTime which both could trigger an replSetUpdatePosition request to the upstream. So it's possible that sometimes the one triggered by the change of lastDurable is blocked behind the the one triggered by the change of lastApplied, causing extra latency in {j: true} majority commit acknowledgement.

We could relax the constraint when the replSetUpdatePosition is triggered by the node itself instead of the forwarded. This may still not be perfect when nodes are chained, but could be sufficient for short term.

We should perf test the change and see if it results in improvement.