Flavio, so I figured out what was holding me up before. In an earlier comment you said the following, "Regarding init(), we first use the value of zxid to determine which log files to read: all log files tagged with a value higher than zxid and the last log file that is less than zxid. Next we iterate over the log files until hdr.getZxid() is greater or equal to zxid (should be zxid really). This guarantees that the next call to next(), after init() returns, will return zxid+1." This is true almost all the time. It is true when we have the requested zxid in our log, but NOT if the very first log entry is zxid+1, which can easily be the case in almost any startup scenario. I am betting that the loop in restore() was originally planned to be coded as you stated (by initializing with last lastProcessedTxnID and then calling next()), but then the issue I mentioned came up and it was decided it was ok to just use the first header, and call next afterward. Without rewriting parts of the TxnIterator, I don't think restructuring that loop in restore() is simple. Therefore, I propose that we simply request lastProcessedZxid+1 from the log initially (which is guaranteed to either be present, or have no entries at all in the log). I am about to submit a patch, with a unittest for this.