nick-boss-tech opened a new pull request, #5130: URL: https://github.com/apache/solr/pull/5130
🤖 *AI text below* 🤖 *(posted on behalf of Nick Shanin)* https://issues.apache.org/jira/browse/SOLR-4374 ## What happens today **A top-level item in `fl` that starts with a digit is not read as a field name.** Before this change, [getFieldName](https://github.com/nick-boss-tech/solr/blob/cabedd1d968059215188f4e7563fb303241899ed/solr/core/src/java/org/apache/solr/search/SolrReturnFields.java#L219-L238) accepted a name only when its first character can start a Java identifier. A name such as `1001` fails that test and falls through to the function parser, which reads the number as a constant. The ticket shows the result: `fl=1001` returns the number 1001 under the key `1001`, not the value of a field named `1001`. ## What this change does **A top-level item that starts with a digit is read as a field when the schema has a field with that name.** When the normal name check fails, the parser tries the digit-leading name against the schema. The lookup covers explicit fields and dynamic field matches ([helper](https://github.com/nick-boss-tech/solr/blob/801c62290f79483e714e88f907a6564e504dfca5/solr/core/src/java/org/apache/solr/search/SolrReturnFields.java#L240-L264), [call site](https://github.com/nick-boss-tech/solr/blob/801c62290f79483e714e88f907a6564e504dfca5/solr/core/src/java/org/apache/solr/search/SolrReturnFields.java#L286-L289)). If the name is not in the schema, the parser position is restored and the item is handled as before. Behavior change, stated openly: a catch-all dynamic field, such as `*`, matches every name. In a schema with one, a top-level number such as `fl=1.5` is read as a field name instead of a constant. Without a catch-all, a number is read as a field only when the schema names that exact field. ## Proof **The new test fails on the base code and passes with this change.** [ReturnFieldsTest](https://github.com/nick-boss-tech/solr/blob/801c62290f79483e714e88f907a6564e504dfca5/solr/core/src/test/org/apache/solr/search/ReturnFieldsTest.java#L399-L406) adds `testDigitLeadingFieldName`, which checks `fl=1001_s,id` against the `*_s` dynamic field. With the new test file on the base source, the class runs 16 tests with one failure, in `testDigitLeadingFieldName`. With this change, at head `801c62290f7`, `ReturnFieldsTest` passes 16 of 16. Verified 2026-10-07 at this head. ## A choice to check **The ticket asks to remove the identifier check. This change keeps the check and adds a schema lookup.** The other route, which the ticket suggests, is to accept every name that starts with a digit as a field. That is simpler. Its cost is that a top-level number in `fl` stops being a constant. The route taken keeps constants and reads a number as a field only when the schema has that field. Its cost is the catch-all case above. Was the schema lookup the right call? ## Limits **The test covers a dynamic field, not the ticket's exact case.** - The test uses `1001_s`. The ticket's example is a field defined as `1001`. That exact case is not tested. - A rename such as `x:1001` is not changed. The rename path still reads names with the stricter check. A follow-up can cover it if maintainers want that. - No other test class was run for this change. Changelog: [changelog/unreleased/SOLR-4374-digit-leading-field-in-fl.yml](https://github.com/nick-boss-tech/solr/blob/801c62290f79483e714e88f907a6564e504dfca5/changelog/unreleased/SOLR-4374-digit-leading-field-in-fl.yml#L1-L8) ### AI assistance AI agents assisted with research, implementation, review, and drafting. Nick Shanin directed the work and takes responsibility for this contribution. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
