The expectation was that issuing a transaction commit causes the LGWR buffer to flush, but this is only applicable to the current transaction and not other transactions that may be in progress at the time. The processing logic was taking the endScn as the starting boundary for subsequent mining sessions and this could lead to events being lost.

For example, lets take a mining session from [1000, 1099]. If events near the end of the boundary are still in the LGWR buffer and aren't flushed to the redo logs, then the mining session would only get a subset of the records. The processor returned the endScn which is 1099 in this case as the starting point for the next iteration but if events 1090 through 1099 were still in the LGWR buffer, they would be skipped and not emitted.

The solution is by default, we cannot take the endScn value as an absolute breakpoint in the mining iterations but instead need to compare it to the last processed Scn we got from the result-set. If the last processed Scn is before the endScn value, then we need to use the lastProcessedScn as the starting point for the next iteration instead.