skippable exception thrown in ItemWriter triggers new chunk within the old transaction

This issue was reported on stackoverflow: https://stackoverflow.com/questions/77187746/jberet-skippable-exception-thrown-in-itemwriter-triggers-new-chunk-within-the-ol

Using JBeret I execute a simple job with single chunk based step which reads entries from the database, processes them and updates it. The step also defines a ChunkListener which interacts with the database as well and a list of skippable exception classes.

An example of such a job is:

<job id="testJob" xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="1.0">
  <step id="test">
    <listeners>
      <listener ref="someChunkListener"/>
    </listeners>
    <chunk item-count="1" >
      <reader ref="testReader" />
      <processor ref="testProcessor"/>
      <writer ref="testWriter"/>
      <skippable-exception-classes>
        <include class="java.lang.IllegalStateException"/>
      </skippable-exception-classes>
    </chunk>
  </step>
</job>

I have observed the following flow:

Transaction has been started for the chunk
The someChunkListener beforeChunk is triggered
The ItemReader is triggered
The ItemProcessor is triggered
*The ItemWriter is triggered causing an IllegalStateException
*The someChunkListener beforeChunk is triggered
The ItemReader is triggered on new chunk
...
What I found strange is that between step 5) and step 6) no new transaction is started, but a new chunk has started/the chunk has restarted.

I tried looking into the JSR-352 specification, but I could not find such behavior described. I looked at the pseudo codes provided there, but I could not find a single pseudo code which suggests that a new chunk may be started (beforeChunk on the chunk listener may be called) but the old transaction is used. I also looked at the JBeret implementation of ChunkRunner and it seems that the prevention of starting of a new transaction is intentional.

To me it seems natural that in this situation either no beforeChunk callback would be called (we continue in the same chunk) or a new transaction would exist for our chunk.

I'm worried that I cannot find a well specified transaction boundaries on chunk based jobs. How should I handle possible dirty transactions based on partially written items or updates from the chunk listeners or even sending a JMS messages via XA Transaction?

Is this behavior JBeret behavior described somewhere along with other similar behavior? Is it a bug, or something JSR-352 specific I didn't look at?