Skip to content

fix: remove indexFieldMap entry by field key, not running counter - #977

Open
Aias00 wants to merge 1 commit into
apache:mainfrom
Aias00:fix/classutils-indexfieldmap-remove-key
Open

fix: remove indexFieldMap entry by field key, not running counter#977
Aias00 wants to merge 1 commit into
apache:mainfrom
Aias00:fix/classutils-indexfieldmap-remove-key

Conversation

@Aias00

@Aias00 Aias00 commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

Summary

Fixes #976.

When a WriteHolder excludes a column, the ignored branch removed from indexFieldMap using the running loop counter index instead of the field's own sortedFieldMap key. For explicit-index fields, that key (entry.getKey()) equals the field's @ExcelProperty(index) — its indexFieldMap key — so removing by the counter dropped an unrelated explicit-index entry and left the ignored field's entry in place.

Root cause

ClassUtils.doDeclaredFields:

if (writeHolder.ignore(field.getFieldName(), entry.getKey())) {
    ignoreSet.add(field.getFieldName());
    indexFieldMap.remove(index);   // BUG: 'index' is the running counter, not the field's key
} else {
    ...
}

indexFieldMap is keyed by the field's explicit @ExcelProperty(index = N) (see declaredOneField), and for explicit-index fields the sortedFieldMap position entry.getKey() equals that index (see buildSortedAllFieldMap). So the ignored field's own entry is keyed by entry.getKey(), not the counter.

Fix

indexFieldMap.remove(key);

For a field with an explicit index, key == entry.getKey() is its indexFieldMap key, so its own entry is removed; for a field without an explicit index, key is not in indexFieldMap, so the call is a no-op (correct — it was never there).

The corruption is observable downstream: ExcelHeadProperty.initColumnProperties passes indexFieldMap.containsKey(entry.getKey()) as forceIndex into each Head, which DefaultAnalysisEventProcessor reads to drive head-to-column matching.

Verification

Added ClassUtilsTest.test_declaredFields_WriteHolder_exclude_preservesUnrelatedExplicitIndex: with ComplexEntity (id index 0, name index 2, email order 10), excluding email must keep indexFieldMap as {0: id, 2: name}. Before the fix id (index 0) was wrongly removed; after the fix it stays. Full fesod-sheet suite: Tests run: 668, Failures: 0.

…ache#976)

When a WriteHolder excludes a column, the ignored branch removed from
indexFieldMap using the running loop counter instead of the field's own
sortedFieldMap key (which equals its explicit @ExcelProperty(index) for
explicit-index fields). This dropped an unrelated explicit-index entry and
left the ignored field's entry in place, corrupting Head.forceIndex
downstream. Remove by entry.getKey() instead; add a regression test.
Copilot AI review requested due to automatic review settings July 27, 2026 23:58

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug] ClassUtils removes the wrong indexFieldMap entry when excluding a column

2 participants