Direct answer
Yes—karate.filter treats the end index as exclusive, consistent with Java List.subList semantics. The array length does not vary between parallel threads; each Scenario Outline iteration receives its own start and end indices. No, do not use modulo for the end index. The recommended pattern is to clamp the end value per iteration with Math.min(start + pageSize, karate.size(array)).
Likely explanation vs. confirmed facts
The one-element shift is an indexing artifact, not a thread-safety problem. When the array length is not an exact multiple of the page size, the last iteration's end index (start + pageSize) exceeds the array bounds. Because the end index is exclusive, the final slice is shorter than expected, which makes earlier or later pages look shifted when concatenated. Confirmed behavior: karate.filter does not automatically clamp the end index, and exceeding the array length can throw an IndexOutOfBoundsException that may be silently swallowed, yielding a short slice. Using modulo would create incorrect boundaries; clamping is the correct fix.
Steps for this case
- Load the array once outside the Scenario Outline so all threads read the same immutable list.
- Derive
start from the Examples row (e.g., __num * pageSize).
- Compute the end index inline:
Math.min(start + pageSize, karate.size(data)).
- Call
karate.filter(data, 'true', start, end) and assert the slice length equals end - start.
Scoped verification:
Scenario Outline: paginate
* def start = __num * pageSize
* def end = Math.min(start + pageSize, karate.size(data))
* def page = karate.filter(data, 'true', start, end)
* match page.length == end - start
Examples:
| pageSize | __num |
| 5 | 0 |
| 5 | 1 |
| 5 | 2 |
| 5 | 3 |
| 5 | 4 |
Verification
Run with @parallel=true against a known array (e.g., 23 elements, page size 5). Confirm that concatenated pages equal the original array in order with no duplicates or gaps. Repeat with an exact multiple to ensure clamping does not alter even divisions.
One diagnostic that changes the recommendation
Which Karate version are you using? Index handling in versions prior to 1.2.0 may have differed; if you are on an older release, verify the clamping behavior against that version before relying on it.
karatelabs