Report a bulk update which failed because the document is missing (#4926)

[batrived]

Fixes #4926.

pairErrorsWithSubmittedMutation removed every bulk item whose status is 404 from the failure list, whatever operation produced it. That is right for a delete — deleting an absent document leaves the index in the state the deletion asked for — but an update returning 404 is a document_missing_exception, and the write did not happen.

Combined with mutate() withholding the upsert whenever a mutation has both deletions and additions, changing a SINGLE cardinality indexed property on an element whose document is absent silently no-ops, permanently, with no exception, no log line and no metric. mutate returns normally, so even indexProvider.<name>.mutate.exceptions stays at zero.

Change

This implements option (1) from the issue. RequestBytes already reads request.getRequestType() to decide on the retry_on_conflict parameter but did not keep it, so retaining it makes the operation available where the failure is interpreted. The exemption is then limited to delete items.

Why I did not also do option (2)

Option (2) — always supplying the upsert — would make the 404 impossible rather than merely visible, and I started there. But mutation.getAdditions() for a SINGLE cardinality value change holds only the changed property, not every indexed property of the element. Upserting from it would create a document containing just that one field, so the element becomes findable by the changed property while still missing the others. That trades a detectable failure for a silently partial document, which I think is the worse of the two.

Making the 404 impossible properly means upserting a document built from the element's full indexed state, which is what restore() already does, and that is a larger change than this fix. Surfacing the error keeps the existing repair paths — transaction log recovery and reindex — in charge of rebuilding the document. Happy to follow up with the upsert version if you would rather have it, or to reconsider if you think the partial document is acceptable.

Behaviour change to be aware of

A mutation which previously returned normally now raises a PermanentBackendException. For a user whose index has already diverged, commits touching those elements will start failing visibly where they used to pass. That is the intent — the alternative is that the divergence stays invisible — but it is a real change in what a running deployment sees, so it may deserve a changelog note if you want one; say so and I will add it.

Testing

RestClientBulkItemStatusTest covers the delete exemption, an update 404, an index 404, the deletion-plus-addition shape that mutate() actually produces for a SINGLE cardinality value change, a mixed batch where only the genuinely failed item is reported, and a batch where an exempt delete and a reported update arrive together.

I confirmed four of these fail against master with "Expected java.io.IOException to be thrown, but nothing was thrown", which is the silent discard. The existing RestClientRetryTest still passes, so the retry path that also consumes this method is unaffected. Docker was unavailable to me, so I could not run the container-backed Elasticsearch suites locally.

Note on overlap

This touches pairErrorsWithSubmittedMutation and RequestBytes, which my PR #4935 for #4925 also modifies nearby, so whichever merges second will need a small rebase.

---

For all changes:

• Is there an issue associated with this PR? Is it referenced in the commit message?
• Does your PR body contain #xyz where xyz is the issue number you are trying to resolve?
• Has your PR been rebased against the latest commit within the target branch (typically master)?
• Is your initial contribution a single, squashed commit?

For code changes:

• Have you written and/or updated unit tests to verify your changes?
• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0? — no new dependencies
• If applicable, have you updated the LICENSE.txt file, including the main LICENSE.txt file in the root of this repository? — not applicable
• If applicable, have you updated the NOTICE.txt file, including the main NOTICE.txt file found in the root of this repository? — not applicable

[Copilot]

Pull request overview

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Fixes bulk indexing error reporting so that 404 responses are only ignored for mutations that only remove content (e.g., delete / field-deletion), while 404 for additions/updates (i.e., document_missing_exception) is surfaced as a failure to prevent silent no-ops.

Changes:

• Track whether each bulk item “removes content only” and use it when interpreting bulk item failures.
• Narrow the “ignore 404” behavior to content-removal mutations rather than all operations.
• Add unit coverage for mixed bulk batches and the delete-vs-update 404 distinction.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
janusgraph-es/src/main/java/org/janusgraph/diskstorage/es/rest/RestElasticSearchClient.java	Retains mutation intent per bulk item and updates bulk error pairing to only exempt 404s for removal-only operations.
janusgraph-es/src/main/java/org/janusgraph/diskstorage/es/ElasticSearchMutation.java	Adds removesContentOnly metadata and introduces a factory for field-deletion updates.
janusgraph-es/src/main/java/org/janusgraph/diskstorage/es/ElasticSearchIndex.java	Switches field-deletion script updates to use the new “removes content only” mutation factory.
janusgraph-es/src/test/java/org/janusgraph/diskstorage/es/rest/RestClientBulkItemStatusTest.java	Adds tests validating 404 handling for deletes, field deletions, and updates in bulk responses.

---

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