Feature Summary
ArrowTableTupleProvider tracks row positions using the first column's chunk layout and applies those chunk coordinates to every column. Valid Arrow tables can have different chunk boundaries per column, causing later fields to throw IndexError or read the wrong position.
Before: different column chunk boundaries -> second row throws IndexError
After: different column chunk boundaries -> rows are read by global index
Reproduction evidence:
Create a three-row Arrow table whose first column has chunk lengths 2 and 1 while its second column has chunk lengths 1 and 2. Read the second row through ArrowTableTupleProvider.
Version and commit evidence:
1.3.0-incubating-SNAPSHOT (main)
Commit Hash
70c2114
What browsers are you seeing the problem on?
Not browser-specific.
Relevant log output
chunk_layouts= [2, 2]
row1= 1 10
row2_a= 2
IndexError: index out of bounds
Proposed Solution or Design
Read each Arrow column by global row index instead of reusing the first column's chunk coordinates.
Affected Area
Workflow Engine (Amber)
Feature Summary
ArrowTableTupleProvider tracks row positions using the first column's chunk layout and applies those chunk coordinates to every column. Valid Arrow tables can have different chunk boundaries per column, causing later fields to throw IndexError or read the wrong position.
Before: different column chunk boundaries -> second row throws IndexError
After: different column chunk boundaries -> rows are read by global index
Reproduction evidence:
Create a three-row Arrow table whose first column has chunk lengths 2 and 1 while its second column has chunk lengths 1 and 2. Read the second row through ArrowTableTupleProvider.
Version and commit evidence:
1.3.0-incubating-SNAPSHOT (main)
Commit Hash
70c2114
What browsers are you seeing the problem on?
Not browser-specific.
Relevant log output
Proposed Solution or Design
Read each Arrow column by global row index instead of reusing the first column's chunk coordinates.
Affected Area
Workflow Engine (Amber)