nick-boss-tech commented on PR #5194: URL: https://github.com/apache/solr/pull/5194#issuecomment-6348212457
🤖 *AI text below* 🤖 *(posted on behalf of Nick Shanin)* The "Behavior change" section says new fields are queryable after the next commit. That is incomplete. A facet on a new field before a commit fails with `undefined field` on every replica. Our test shows this on this head: [diff of our test against this PR](https://github.com/apache/solr/compare/linslee75:SOLR-18563-additive-schema-api-no-reload...nick-boss-tech:solr:solr-18563-searcher-reopen). The same facet passes on upstream main for the replica that receives the request. The other replicas fail, so main is already uneven. Options: 1. **Reopen the searcher on every replica after an additive change.** Queries see the new field as soon as the command returns, as they do today. Cost: one searcher open per replica for each schema request. 2. **Keep the change and document the failure.** The Behavior change section and changelog would say that facets and other queries on the field can fail until a commit. Cost: a visible change from today on every replica. 3. **Keep the reload in SolrCloud and skip it only in standalone.** Cost: the merge-blocking problem this PR fixes stays in SolrCloud. **Recommendation: option 1.** We built it, and it passes our gate. The diff is [here](https://github.com/apache/solr/compare/linslee75:SOLR-18563-additive-schema-api-no-reload...nick-boss-tech:solr:solr-18563-searcher-reopen). It has three commits: our test, a few lines in `SchemaManager` and `ZkIndexSchemaReader` that open the searcher after an additive change, and a guard so a replica does not open a searcher on a core that is closing. Our first gate run caught that case: a reload closes the old core, and its schema watcher can still fire afterwards. On this branch the facet passes on every replica. `TestManagedSchemaAPI` passes 7 of 7 and `TestBulkSchemaAPI` passes 19 of 19. The module check passes. We have not measured the cost of the extra searcher. **Bottom line: take option 1.** It keeps queries working right after the command and keeps the merge-blocking fix. Option 2 turns an uneven result into a consistent failure that users will hit. Option 3 gives up the fix for SolrCloud, which is where the PR's problem is. -- 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]
