For initial sync, we have the beginFetchingTimestamp which tells us when to start retrieving the oplog to make sure we have all partial transactions, and the beginApplyingTimestamp which tells us when to start applying those oplog entries (anything before that is assumed to have been applied).  If an oplog application batch has partial entries for a transaction before and including beginApplyingTimestamp, and a commit or prepare entry after, these entries may not have been written to the oplog and will not be found, causing an fassert.

There are two possible ways to fix this:

1) Always place a batch boundary just after beginApplyingTimestamp (the oplog entry with that timestamp is not applied  or

2) "Apply" partial transactions even when they are <= the beginApplyingTimestamp.

The first should be more straightforward, as the second requires special handling of commit, abort, and prepare also (it must clear the partial transaction list for that transaction for the current batch)