SOLR-18627: ignored fields throw NPE since StrField.createFields() switched to List.of by linslee75 · Pull Request #5305 · apache/solr

linslee75 · 2026-11-06T06:15:16Z

https://issues.apache.org/jira/browse/SOLR-18627

Dev list: subject "ignored fields throw NPE since Solr 10.1"

Description

Writing a document that contains an ignored field works on Solr 10.0 and throws a NullPointerException on 10.1. The whole update is rejected with 400, not just the ignored field.

The demo config has dynamicField ignored_* of type ignored:

curl http://localhost:8983/solr/demo/update/json/docs \
  -H 'Content-Type: application/json' \
  -d '{"id":"test","ignored_field":"foobar"}'

Solr 10.0 returns status 0. Solr 10.1 returns status 400.

This was reported on users@:
https://lists.apache.org/thread.html/28pqz7gkvr3tb3mrj7f9npvs8f6slqq5

David Smiley confirmed on dev@ that this is not the expected behavior, and that a test is missing.

Cause

ignored is a StrField that is not indexed, not stored, and has no docValues. FieldType.createField() returns null for that case, and DocumentBuilder already skips null fields.

StrField.createFields() used to return Collections.singletonList(fval), which accepts null. Since 10.1 it returns List.of(fval), which does not. The NPE is thrown before the field is dropped.

Fix

Return an empty list when fval is null, matching FieldType.createFields().

Tests

BasicFunctionalityTest.testIgnoredFields: verifies that a document containing an ignored StrField can be indexed and queried successfully.

AI disclosure: I used an AI coding assistant for the investigation and this description. I reviewed and verified the change.

…itched to List.of Collections.singletonList accepted the null from createField(). List.of does not, so the whole document was rejected.

github-actions · 2026-11-06T06:15:41Z

Automated PR triage (LLM-generated; may be wrong). Checked once, when the PR was opened or marked ready; not updated on later pushes.

No clear mismatches in the answered judgements.

	Warranted?	In PR?	Confidence	Why
✅ Jira issue in title	—	yes	—	Already present; not judged.
✅ Changelog	fixed	fixed	high	The change fixes a NullPointerException that caused document updates to fail with a 400 error when writing ignored fields, which is a user-visible bug fix.
✅ Reference Guide update	no	no	high	This is a bug fix restoring expected behavior; it does not introduce new configuration, parameters, or user-facing features that require documentation updates.
✅ Upgrade notes	no	no	high	The change is a bug fix that restores previous behavior and is not backwards-incompatible.
✅ Tests	yes	yes	high	The PR modifies production logic in StrField.java to handle null values, and the description explicitly mentions adding a test (StrFieldTest.testIgnoredFieldCanBeWritten) to cover this scenario.

⚠️ mismatch, ❔ uncertain or unanswered, ✅ agrees. Matching changelog, docs and test files were hidden from the model; the PR description may still mention them. File presence does not establish adequacy. Assessed commit e4826464b1e8f04da9d1092a4ff62b44c57a2def.

linslee75 · 2026-11-06T07:08:58Z

I checked the other createFields() overrides that return List.of(createField()). BoolField, BinaryField, SortableTextField, CollationField, and ICUCollationField have the same shape, but only when indexed, stored, and docValues are all false. The ignored field type is a StrField, and that is the reported case, so this PR only changes StrField.

epugh · 2026-11-06T12:00:23Z

      fval = docval;
    }
-    return List.of(fval);
+    return fval == null ? List.of() : List.of(fval);


that sucks that we have to do this check! I guess technically if fval is null, then the List.of is return a list with a single value, null instead of an empty list?

Out of curiosity, are we doing something wrong that we trigger this pattern? I'm wondering if our coding style conflicts with how Java thinks we should do things... Or is this just totally normal java code? If it isn't totally normal java code, I wonder if there are other places we follow this pattern that are latent bugs?

Lastly, if return List.of(fval); is bad form, is there a errorprone or other checker rule that we could enable?

FieldType.createFields already does f == null ? List.of() : List.of(f), and SOLR-18164 kept that check. createField() returns null when the field is neither indexed nor stored, and List.of(null) throws, so StrField now uses the same check. I don't have a better idea for now.

epugh · 2026-11-06T12:01:28Z

I checked the other createFields() overrides that return List.of(createField()). BoolField, BinaryField, SortableTextField, CollationField, and ICUCollationField have the same shape, but only when indexed, stored, and docValues are all false. The ignored field type is a StrField, and that is the reported case, so this PR only changes StrField.

I just saw this. So, are you saying that BoolField etc all have the same problem?

linslee75 · 2026-11-06T12:16:29Z

I checked the other createFields() overrides that return List.of(createField()). BoolField, BinaryField, SortableTextField, CollationField, and ICUCollationField have the same shape, but only when indexed, stored, and docValues are all false. The ignored field type is a StrField, and that is the reported case, so this PR only changes StrField.

I just saw this. So, are you saying that BoolField etc all have the same problem?

Yes. Those overrides call List.of(createField()) with no null check. They throw only when indexed, stored, and docValues are all false. The ignored type is a StrField, which is the case this PR fixes.

nick-boss-tech · 2026-11-06T17:05:22Z

LGTM.
Nit: The PR description names the old test.
I have prepared a branch for the other field types, will submit after this merges unless @linslee75 prefers to do that.

linslee75 · 2026-11-07T02:35:13Z

LGTM. Nit: The PR description names the old test. I have prepared a branch for the other field types, will submit after this merges unless @linslee75 prefers to do that.

Thanks, Nick! I’d be happy to let you handle the follow-up PR for the other field types. Thanks for preparing the branch and looking into this!

epugh · 2026-11-07T17:44:22Z

Humm.. So, do the other field types have the same issue? If so, feels like this one PR should solve them unless it's a huge code change? whats the advantage to having multiple PRs? If the same problem affects multipole fields, then I'd rather review and test one PR...

nick-boss-tech · 2026-11-07T18:59:02Z

@linslee75, I’ve prepared the sibling fixes and tests on top of your current PR head. You’re welcome to take them into this PR:

View the additional changes

From your PR branch, you can bring in the commit with:

git switch SOLR-18627-ignored-field-npe
git fetch https://github.com/nick-boss-tech/solr.git pr-5305-solr-18627-ignored-fields
git merge --ff-only 5df2caa0e59a9bbbd0d6e91e74bfbfc80797b69f

The added tests cover ignored fields and include docValues-only checks. Linux verification of the revised commit is pending.

dsmiley · 2026-11-08T04:44:59Z

Agreed we should all occurrences of the bug in this PR.

Nick; thanks for the additions, although I feel the LOC added for the tests isn't warranted.

linslee75 · 2026-11-08T04:57:04Z

@linslee75, I’ve prepared the sibling fixes and tests on top of your current PR head. You’re welcome to take them into this PR:

View the additional changes

From your PR branch, you can bring in the commit with:
git switch SOLR-18627-ignored-field-npe
git fetch https://github.com/nick-boss-tech/solr.git pr-5305-solr-18627-ignored-fields
git merge --ff-only 219fee78bf7cae5039e50fe885108a1d4937ccd3
The added tests cover ignored fields and preserve docValues-only behavior.

One question about the changes that delegate to super.createFields().

Before Solr 10.1, these field types had their own createFields() implementations, including the DocValues handling.

Since your changes move some of this logic to the parent implementation, do you think we need focused tests to verify that the existing behavior is preserved, particularly for DocValues and multi-valued fields?

I just want to make sure this change does not introduce unintended behavior differences.

linslee75 · 2026-11-09T03:08:32Z

The other field types are now covered in this PR. Each createFields() override uses the same null check as FieldType.createFields, and testIgnoredFields writes a document for each of them.

Thanks, @nick-boss-tech , for finding those field types and preparing a branch.

nick-boss-tech · 2026-11-09T19:51:06Z

Thanks, it looks good to me.

SOLR-18627: ignored fields throw NPE since StrField.createFields() sw…

e482646

…itched to List.of Collections.singletonList accepted the null from createField(). List.of does not, so the whole document was rejected.

github-actions Bot added tests cat:schema labels Nov 6, 2026

SOLR-18627: Cover ignored StrField indexing in testIgnoredFields

00292cd

linslee75 force-pushed the SOLR-18627-ignored-field-npe branch from 735f5d9 to 00292cd Compare November 6, 2026 11:22

epugh reviewed Nov 6, 2026

View reviewed changes

dsmiley mentioned this pull request Nov 6, 2026

PR triage: compact bullet comment; judge again on every ready_for_review #5308

Merged

SOLR-18627: Avoid NPE from List.of when other field types are ignored

6b15133

github-actions Bot added the test-framework label Nov 9, 2026

Conversation

linslee75 commented Nov 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Cause

Fix

Tests

Uh oh!

github-actions Bot commented Nov 6, 2026

Uh oh!

linslee75 commented Nov 6, 2026

Uh oh!

epugh Nov 6, 2026

Choose a reason for hiding this comment

Uh oh!

linslee75 Nov 6, 2026

Choose a reason for hiding this comment

Uh oh!

epugh commented Nov 6, 2026

Uh oh!

linslee75 commented Nov 6, 2026

Uh oh!

nick-boss-tech commented Nov 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

linslee75 commented Nov 7, 2026

Uh oh!

epugh commented Nov 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nick-boss-tech commented Nov 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dsmiley commented Nov 8, 2026

Uh oh!

linslee75 commented Nov 8, 2026

Uh oh!

linslee75 commented Nov 9, 2026

Uh oh!

nick-boss-tech commented Nov 9, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

linslee75 commented Nov 6, 2026 •

edited

Loading

nick-boss-tech commented Nov 6, 2026 •

edited

Loading

epugh commented Nov 7, 2026 •

edited

Loading

nick-boss-tech commented Nov 7, 2026 •

edited

Loading