You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@fesod.apache.org by "Sean-Walker0 (via GitHub)" <gi...@apache.org> on 2026/10/19 02:05:53 UTC

[PR] fix(sheet): give head-row handler contexts their real row index [fesod]

Sean-Walker0 opened a new pull request, #1234:
URL: https://github.com/apache/fesod/pull/1234

   ## Purpose of the pull request
   
   When writing a multi-row head, `WriteContextImpl.initHead` created the `RowWriteHandlerContext` for **every** head row with the same starting row index instead of the loop's row index. A two-row head reported `rowIndex=0` twice (while `relativeRowIndex` correctly said 0 then 1), a three-row head reported 0 three times, and so on. Any `RowWriteHandler` (or code reached from one) that keys on `getRowIndex()` — custom position checks, per-row styling, writing markers or comments at computed positions — saw wrong indexes for every head row after the first. Data-row contexts were already correct.
   
   Observed with a registered handler on a 2-row-head write (default settings):
   
   ```
   rowIndex=0 relative=0 isHead=true   firstCell=c0r0
   rowIndex=0 relative=1 isHead=true   firstCell=c0r1   <-- should be 1
   rowIndex=2 relative=0 isHead=false  firstCell=v0
   rowIndex=3 relative=1 isHead=false  firstCell=w1
   ```
   
   No issue exists for this yet; found while probing handler context values.
   
   ## What's changed?
   
   The context is now created with the loop's row index `i` instead of the constant `newRowIndex` — one line. The physical rows themselves were always written at `i` (`WorkBookUtil.createRow(sheet, i)`), so handlers now see the index of the row they are actually observing.
   
   ## Checklist
   
   - [x] I have read the [Contributor Guide](https://fesod.apache.org/community/contribution/).
   - [x] I have written the necessary doc or comment.
   - [x] I have added the necessary unit tests and all cases have passed.
   
   ## Verifying this change
   
   - `HeadRowHandlerContextTest` — red before (`head rows must report their physical row indexes ==> expected: <[0, 1]> but was: <[0, 0]>`), green after; data rows 2 and 3 are pinned on both sides.
   - `WriteHandlerTest` (the handler call-matrix suite): 23/23 unchanged.
   - `./mvnw clean package -B -Dmaven.test.skip=false -pl fesod-common,fesod-shaded,fesod-sheet`: 1119 tests, 0 failures, 0 errors.
   - `./mvnw -pl fesod-sheet spotless:check`: clean.
   
   ## Notes
   
   - Behavior change: `RowWriteHandlerContext.getRowIndex()` for head rows after the first now reports the real row index. Handlers that (knowingly or not) relied on the constant value would observe different indexes — the old value was inconsistent with the written row and with `relativeRowIndex`, so this is the fix's intent.
   - The same constant-index pattern exists in the EasyExcel lineage upstream; this is a parity fix, not a fesod regression.
   - Orthogonal to open PRs: #1209 (context recycling) refactors the same `createRowWriteHandlerContext` call site but the index argument flows through either shape and the diffs merge cleanly; #920/#1076 touch other regions of `WriteContextImpl`.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@fesod.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@fesod.apache.org
For additional commands, e-mail: commits-help@fesod.apache.org