During the oplog application phase of initial sync we advance the oldest timestamp after applying each batch of oplog entries. We end up setting the oldest timestamp with force set to true. This ends up hitting an invariant if we applied a resharding oplog entry that requests to pin the oldest timestamp.

I don't think that initial sync needs to use force when setting the oldest timestamp. In all cases we should be moving the oldest timestamp forward, and I think we only set the oldest timestamp during the oplog application phase to clean up history, so I think it should be fine to pin oldest back for an operation like resharding as long as the initial syncing node does not succeed in serving a read for resharding. On the other hand, we should not be able to do reads before the initialDataTimestamp anyways, so another option is that we ignore pinning the oldest timestamp if we are still in initial sync.