SOLR-6973: A partial update with no signature fields no longer gets an empty signature, which can delete unrelated documents

[nick-boss-tech]

🤖 AI text below 🤖 (posted on behalf of Nick Shanin)

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

What happens today

With overwriteDupes, a partial update with no signature fields can delete unrelated documents.

With a fields list, the processor's loop throws only if a signature field is present in the partial update. A partial update that sets other fields passes the loop with an empty signature. The processor writes that signature to signatureField and sets updateTerm to it (SignatureUpdateProcessorFactory.java). updateDocuments deletes every document that matches updateTerm (DirectUpdateHandler2.java).

What this change does

A partial update with no signature fields skips the signature step.

It goes to the next processor unchanged. Partial updates with a signature field still fail, and requests without fields still reject partial updates (SignatureUpdateProcessorFactory.java).

Behavior change: a partial update that creates a new document now stores it without signatureField. The old code gave it the shared empty signature, which caused the collision.

Proof

The new test fails on the base code and passes with this change.

The test is SignatureUpdateProcessorFactoryTest.java. It checks that signatureField is absent and updateTerm is null. On the base production code, the same class ran 7 tests with 1 failure. The failure is the new test: the base code sets both values it checks for absence.

With this change, the focused SignatureUpdateProcessorFactoryTest ran 7 of 7, verified 2026-10-09 at head 51fcd05e695. The head includes a review fix that decides the partial-update outcome before the signature class is constructed; the same 7 tests and the same base failure were re-verified at that head. The core module checks also pass.

A choice to check

The update passes through. The other option is to reject it.

The no-fields setup already rejects partial updates with an error. This change passes them through, so the update works and no signature is stored. Rejecting would make the failure visible but would stop the update. Was pass-through the right call?

Limits

The reporter's 5% symptom is not shown to come from this path.

The ticket comments suggest shard routing. This change removes one collision path. It does not show that the path explains the report. The effect on new documents was checked by reading only. A follow-up submission is planned if the shard-routing path is confirmed as the cause of the reported symptom.

Changelog: changelog/unreleased/SOLR-6973-signature-partial-update.yml

AI assistance

AI agents assisted with research, implementation, review, and drafting. Nick Shanin directed the work and takes responsibility for this contribution.

[Copilot]

🟡 Changes recommended

Determine whether a signature field is present before constructing and initializing the signature implementation.

1 open finding

• Avoid constructing signature when no signature fields are present · New

What changed in this PR

This pull request prevents partial updates without signature fields from generating an empty deduplication signature.

Changes:

• Bypasses signature generation for unaffected partial updates.
• Adds regression coverage.
• Adds a SOLR-6973 changelog entry.

File	Description
solr/​core/​src/​test/​org/​apache/​solr/​update/​processor/​SignatureUpdateProcessorFactoryTest.java	Verifies pass-through behavior without a signature or update term.
solr/​core/​src/​java/​org/​apache/​solr/​update/​processor/​SignatureUpdateProcessorFactory.java	Skips signature assignment for eligible partial updates.
changelog/​unreleased/​SOLR-6973-signature-partial-update.yml	Documents the fix.

🧠 Review effort: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.