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
IndexNameExpressionResolver should not ignore any wildcards #13384
Conversation
@@ -604,6 +596,14 @@ public long getStartTime() { | |||
.stream() | |||
.filter(e -> Regex.simpleMatch(pattern, e.getKey())) | |||
.collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue)); | |||
} else { |
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.
I'd probably keep the clauses in the order they were in before. Not a big deal though.
Left a small comment otherwise it LGTM. |
Thx @nik9000 :-) |
80dd9d2
to
9a20773
Compare
Do we need this for 2.0 and 2.1 @clintongormley ? |
Almost certainly 2.1 (2.x branch) and probably not 2.0. Its a bug and doesn't have much chance of breaking anything so I'm for putting it in 2.0 as well. |
LGTM @xuzha @nik9000 @clintongormley I think this bugfix should be backported to 2.x and 2.0 |
elsewhere in the expression, closes elastic#13334
9a20773
to
c6da8d5
Compare
Thanks @nik9000 and @martijnvg for the review. |
thank you @xuzha! |
Suffix wildcard case should work for the expression which only has one wildcard in the end.
Fix for #13334.