Currently, replication applier threads on a secondary are not subject to any back-pressure based on checkpoint progress. Oplog entries applied ahead of the most recent installed checkpoint occupy unevictable cache, but there's no signal to slow down applier thread if this gap grows.

We had a case of a page materialization outage on a secondary cell and applier threads continued applying oplog unthrottled, growing WT dirty cache utilization. By the time the delayed checkpoint was ready to install, there was insufficient cache to read in its metadata, leaving WT permanently cache-stuck with no recovery path short of crashing the node.

We have flow control to prevent cache pressure cases on the secondary but it reacted too late here (~2 min) and the secondary already entered an unrecoverable state.

SERVER-129972 should address the page materialization outage part of this problem, but we should consider a fix at the secondary layer. One option is to throttle applier threads based on how far ahead application is from the last checkpoint.