-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Java issues batch 8 #2959
Java issues batch 8 #2959
Conversation
Following you can find the validation results for the APIs you have changed.
You can validate these APIs yourself by using the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! LGTM. Sorry that I missed it earlier.
export class StepKey { | ||
action: string | ||
name: string | ||
// action and name are optional in case they are used in next_step | ||
action?: string | ||
name?: string | ||
phase: string | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we make a NextStepKey
class? Just wondering, really.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
was wondering the same, that would be a breaking change though and it would have to wait
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed! Can you please add it to #2973?
And feel free to merge this pull request
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not 100% related, but juding from the documentation, it seems that both, current_step
and next_step
should be required.
We currently model them as optional:
/**
* @rest_spec_name ilm.move_to_step
* @availability stack since=6.6.0 stability=stable
*/
export interface Request extends RequestBase {
path_parts: {
index: IndexName
}
body: {
current_step?: StepKey
next_step?: StepKey
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch! I'll remove the optional
Following you can find the validation results for the APIs you have changed.
You can validate these APIs yourself by using the |
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-8.15 8.15
# Navigate to the new working tree
cd .worktrees/backport-8.15
# Create a new branch
git switch --create backport-2959-to-8.15
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 3b1143a5a96fc7596af96485bccca492798d6f0e
# Push it to GitHub
git push --set-upstream origin backport-2959-to-8.15
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-8.15 Then, create a pull request where the |
* [877] ngram and edge tokenizer optional values * [880] _shards optional because of wait_for_completion * [881] added missing allow_custom_routing * [883] action and name optional next_step * both steps mandatory in move to step request (cherry picked from commit 3b1143a)
* [877] ngram and edge tokenizer optional values * [880] _shards optional because of wait_for_completion * [881] added missing allow_custom_routing * [883] action and name optional next_step * both steps mandatory in move to step request (cherry picked from commit 3b1143a) Co-authored-by: Laura Trotta <[email protected]>
wait_for_competion
, so the response should be optional to handle bothwait_for_competion
cases.allow_custom_routing
to PutIndexTemplate. server code -failure_store
is internal.action
andname
are optional. not super clear from the server code (it's all String), but the documentation confirms it (and DevTools test as well).Everything should be safe to backport to 8.x and 8.15