lastDurable is set asynchronously from lastApplied. This can cause us to attempt to advance lastDurable beyond lastApplied. When we attempt to advance lastDurable beyond lastApplied, we skip advancing lastDurable. This can increase latency for w:"majority" writes, which wait for lastDurable to advance on a majority. It also causes odd behavior, where w:1,j:true writes return success, but durableOpTime in replSetGetStatus is not updated. When we attempt to advance lastDurable beyond lastApplied, we should advance both lastDurable and lastApplied.
The comments surrounding this log line suggest that this is unexpected behavior:
Observed on an internal cluster with a primary running 4.4.0-rc3 and secondaries on 4.2.1. Happy to increase logging level if it would be helpful to understand the behavior here.