[inference_metadata_fields] Fix handling of explicit null values for semantic text fields #118947
Conversation
Previously, setting a field explicitly to null in an update request did not work correctly with semantic text fields. This change resolves the issue by adding an explicit null entry to the `_inference_fields` metadata when such cases occur. The explicit null value ensures that any prior inference results are overwritten during the merge of the partial update with the latest document version.
jimczi
added
>non-issue
:SearchOrg/Relevance
|
Pinging @elastic/search-eng (Team:SearchOrg) |
|
Pinging @elastic/search-relevance (Team:Search - Relevance) |
There was a problem hiding this comment.
Thanks for writing up this approach. I agree that we can fix this issue with less refactoring than I originally thought by creating a response accumulator slot when a source field value is explicitly set to null.
However, I think the approach needs some adjustment to handle semantic text fields with multiple source fields. Based on my reading, I think we can handle this case by adding a FieldInferenceResponse with an "empty" ChunkedInference result (i.e. no chunks) when we encounter an explicit null value. This would result in applyInferenceResponses generating an empty chunk list for the applicable source field.
...ain/java/org/elasticsearch/xpack/inference/action/filter/ShardBulkInferenceActionFilter.java
Show resolved
Hide resolved
...ain/java/org/elasticsearch/xpack/inference/action/filter/ShardBulkInferenceActionFilter.java
Show resolved
Hide resolved
|
I created #119145 to follow up on this issue |
Previously, setting a field explicitly to null in an update request did not work correctly with semantic text fields. This change resolves the issue by adding an explicit null entry to the
_inference_fieldsmetadata when such cases occur.The explicit null value ensures that any prior inference results are overwritten during the merge of the partial update with the latest document version.