nick-boss-tech opened a new pull request, #5076:
URL: https://github.com/apache/solr/pull/5076

   🤖 *AI text below* 🤖 *(posted on behalf of Nick Shanin)*
   
   https://issues.apache.org/jira/browse/SOLR-5941
   
   ## What happens today
   
   **An autoCommit never reaches the update processing chain. Processors see 
client commits, but not the timer's commits.**
   
   `CommitTracker` called the core's update handler directly. A processor in 
the default update chain can record, act on, or veto a client commit. It never 
sees an autoCommit.
   
   ## What this change does
   
   **AutoCommits now go through the default chain. They are marked as end 
points, so they stay on the core that ran them.**
   
   - `CommitTracker` marks its synthetic request with `commit_end_point=true` 
([CommitTracker.java](https://github.com/nick-boss-tech/solr/blob/a4df7bfd214b15d9c8d4519fdac8fd6df9468f2d/solr/core/src/java/org/apache/solr/update/CommitTracker.java#L278-L280)).
 It then runs the commit through the default chain 
([L297-L309](https://github.com/nick-boss-tech/solr/blob/a4df7bfd214b15d9c8d4519fdac8fd6df9468f2d/solr/core/src/java/org/apache/solr/update/CommitTracker.java#L297-L309)).
   - The distributed processors act only on the exact string `true`. 
`DistributedZkUpdateProcessor` commits locally and returns. It does this before 
the read-only check and the ZooKeeper checks 
([DistributedZkUpdateProcessor.java](https://github.com/nick-boss-tech/solr/blob/a4df7bfd214b15d9c8d4519fdac8fd6df9468f2d/solr/core/src/java/org/apache/solr/update/processor/DistributedZkUpdateProcessor.java#L158-L163)).
 `RoutedAliasUpdateProcessor` does not route such a request 
([RoutedAliasUpdateProcessor.java](https://github.com/nick-boss-tech/solr/blob/a4df7bfd214b15d9c8d4519fdac8fd6df9468f2d/solr/core/src/java/org/apache/solr/update/processor/RoutedAliasUpdateProcessor.java#L92-L96)).
   - The mark is a request parameter, so any request that carries 
`commit_end_point=true` gets this handling, not only autoCommits. On SolrCloud, 
such a client commit now stays on the node that receives it. Before, a leader 
forwarded it to its replicas, and a non-leader did nothing with it. A 
routed-alias core also skips routing for any request with the parameter, adds 
included.
   - On SolrCloud, each autoCommit now takes a new version from the clock and 
holds the update lock 
([DistributedUpdateProcessor.java](https://github.com/nick-boss-tech/solr/blob/a4df7bfd214b15d9c8d4519fdac8fd6df9468f2d/solr/core/src/java/org/apache/solr/update/processor/DistributedUpdateProcessor.java#L1166-L1192)).
 Before, only a cloud leader's hard commit got a version, and that version is 
replaced on a leader 
([CommitTracker.java](https://github.com/nick-boss-tech/solr/blob/a4df7bfd214b15d9c8d4519fdac8fd6df9468f2d/solr/core/src/java/org/apache/solr/update/CommitTracker.java#L288)).
   - If a replica's update log is not ACTIVE, for example while it buffers 
during recovery, the autoCommit is logged as ignored and not committed 
([DistributedUpdateProcessor.java](https://github.com/nick-boss-tech/solr/blob/a4df7bfd214b15d9c8d4519fdac8fd6df9468f2d/solr/core/src/java/org/apache/solr/update/processor/DistributedUpdateProcessor.java#L1174-L1185)).
 Before, an autoCommit always committed. This branch does not test that case, 
and this description does not claim that a later commit covers it.
   
   ## A choice to check
   
   **The main choice is to route autoCommits through the default chain.**
   
   Options considered:
   
   - Implemented: autoCommits run through the default chain. Processors see 
them and can veto them. The end-point mark keeps each commit on its core. The 
cost: a processor that rejects commits can now stop an autoCommit, and any 
client can set the mark.
   - Keep the direct call, and document that processors do not see autoCommits. 
This route reduces to the reference guide note.
   - Run each autoCommit through the chain its documents arrived by. This needs 
new bookkeeping, which this change does not add.
   
   Was routing autoCommits through the default chain the right call?
   
   ## Proof
   
   **On base, the recording processor never sees an autoCommit. At this head, 
the doc-fix gate passed on 2026-10-09, including the SolrCloud classes.**
   
   - The doc-fix gate finished 2026-10-09. The four focused classes below all 
pass at this head.
   - 
[AutoCommitUpdateChainTest](https://github.com/nick-boss-tech/solr/blob/a4df7bfd214b15d9c8d4519fdac8fd6df9468f2d/solr/core/src/test/org/apache/solr/update/AutoCommitUpdateChainTest.java#L71-L84)
 passes 2 of 2 at this head. Its recording processor sees one autoCommit, 
marked as an autoCommit and as an end point, and the document becomes 
searchable. On base the processor never sees the autoCommit. This was checked 
by reading the base code.
   - 
[CommitThroughNonLeaderTest](https://github.com/nick-boss-tech/solr/blob/a4df7bfd214b15d9c8d4519fdac8fd6df9468f2d/solr/core/src/test/org/apache/solr/cloud/CommitThroughNonLeaderTest.java#L77)
 passes 1 of 1. ParallelCommitExecutionTest passes 1 of 1, and 
HttpPartitionOnCommitTest passes 1 of 1.
   - At this head, tidy and Error Prone compile are clean, the changelog 
parses, and the module check is clean.
   - The earlier focused runs were at the pre-fix submit head `62516cc338e`, 
not at base `cabedd1d968`. The later commits fixed the string read of the flag, 
the test's client builder, and the reference guide sentence.
   
   ## Limits
   
   **The tests cover standalone chain behavior and one SolrCloud path. No live 
multi-node run was made.**
   
   - The autoCommit test is standalone. No test sends a client request that 
carries `commit_end_point=true` through the update handler.
   - Five test classes from the earlier focused run at `62516cc338e` were not 
re-run at this head: DirectUpdateHandlerTest, MaxSizeAutoCommitTest, 
TestUpdate, SolrCmdDistributorTest and DistributedUpdateProcessorTest. That gap 
is accepted, with no re-run.
   - Adjacent, not changed: 
[IgnoreCommitOptimizeUpdateProcessorFactory.java](https://github.com/nick-boss-tech/solr/blob/a4df7bfd214b15d9c8d4519fdac8fd6df9468f2d/solr/core/src/java/org/apache/solr/update/processor/IgnoreCommitOptimizeUpdateProcessorFactory.java#L125)
 reads the same flag with `getBool`. That call throws on the internal values 
`leaders` and `replicas`. This change does not touch that check. A follow-up 
ticket and PR can cover it on request.
   
   Changelog: `changelog/unreleased/SOLR-5941.yml` (type: changed).
   
   ### 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]

Reply via email to