'JBeret (JSR352) rollback expected behaviour

If my understanding is correct, from JSR352 section 8.2.1.4.4 Default Retry Behavior - Rollback:

When a retryable exception occurs, the default behavior is for the batch runtime to rollback the current chunk and re-process it with an item-count of 1 and a checkpoint policy of item

and further from section 8.2.1.4.3 Retry and Skip the Same Exception:

This allows an exception to initially be retried for the entire chunk and then skipped if it recurs.

Accordingly, my expectation is that if a retryable and skippable exception occurs, the "current" chunk is rolled back and restarted with an item-count of 1 and any errors within this "incremental replay period" are skipped.

Subsequently, once the chunksize is reached, processing is returned to the configured size (continue standard processing).

I'm observing some unexpected behaviour where the "failed chunk" gets skipped in its entirety, and the incremental processing starts from the subsequent chunk. Accordingly, I'm missing (one chunks worth of) records.

e.g. Record count moves from 341900 to 342001 below (processing of 341901-342000 is missed):

2022-02-11 16:09:19,233 INFO  [com.MyClass] (executor-thread-0) Reader checkpoint at row 341400
2022-02-11 16:09:20,400 INFO  [com.MyClass] (executor-thread-0) Reader checkpoint at row 341500
2022-02-11 16:09:21,503 INFO  [com.MyClass] (executor-thread-0) Reader checkpoint at row 341600
2022-02-11 16:09:22,692 INFO  [com.MyClass] (executor-thread-0) Reader checkpoint at row 341700
2022-02-11 16:09:23,836 INFO  [com.MyClass] (executor-thread-0) Reader checkpoint at row 341800
2022-02-11 16:09:24,954 INFO  [com.MyClass] (executor-thread-0) Reader checkpoint at row 341900
2022-02-11 16:09:24,995 INFO  [com.MyClass] (executor-thread-0) Closing resource https://example.com/file.xml
2022-02-11 16:09:24,996 INFO  [com.MyClass] (executor-thread-0) Opening resource https://example.com/file.xml
2022-02-11 16:09:31,847 INFO  [com.MyClass] (executor-thread-0) Reader checkpoint at row 342001
2022-02-11 16:09:31,868 INFO  [com.MyClass] (executor-thread-0) Reader checkpoint at row 342002
2022-02-11 16:09:31,888 INFO  [com.MyClass] (executor-thread-0) Reader checkpoint at row 342003
2022-02-11 16:09:31,906 INFO  [com.MyClass] (executor-thread-0) Reader checkpoint at row 342004

Is my understanding correct here, and if so does this look like a bug or am I'm missing some "user obligations" in ItemReader#checkpointInfo().

jberet-core version is 1.4.4.Final, from:

<dependency>
    <groupId>io.quarkiverse.jberet</groupId>
    <artifactId>quarkus-jberet</artifactId>
    <version>1.0.0</version>
</dependency>

Thanks



Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source