Adding allow_partial_search_results parameter to OpenPointInTime action #3155
Conversation
|
Following you can find the validation results for the API you have changed.
You can validate this API yourself by using the |
| }, | ||
| "allow_partial_search_results": { | ||
| "type": "boolean", | ||
| "description": "Specifiy whether to tolerate shards missing from the point in time creation, or throw an exception if any shard is missing. (default: false)" |
There was a problem hiding this comment.
Adding the JSON spec change is a nice touch, thank you! The source of truth is still Elasticsearch, and we have automation that copies over the files from Elasticsearch. Was this file fixed in the Elasticsearch repo too?
There was a problem hiding this comment.
Was about to setup a new PR for that; but good to know that automation will take care of this! Should I remove this part to avoid potential conflicts?
There was a problem hiding this comment.
There was a problem hiding this comment.
Also, just to be on the safe side, would automation also handle backports if needed?
There was a problem hiding this comment.
Yes, the automation handles backports, and your change won't cause a conflict. I do think it's good to have here.
Even if the content ends up being different in Elasticsearch itself, we'll have a PR to review with the updated content.
|
Following you can find the validation results for the API you have changed.
You can validate this API yourself by using the |
allow_partial_search_resultswas made available for theOpenPointInTimerequest in elastic/elasticsearch#111516 but the specs weren't properly updated. This PR adds a newallow_partial_search_resultsparameter to theOpenPointInTimespec, which default tofalse, and specifies whether we should be lenient if a shard is missing when creating a point in time reference, or if we should throw.Closes #3144