Skip to content
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

Add matching pattern to error in fields #76903

Merged
merged 17 commits into from
Sep 1, 2021

Conversation

nik9000
Copy link
Member

@nik9000 nik9000 commented Aug 24, 2021

This adds the pattern into the error message returned when trying to
fetch fields. So this:

POST _search {
  "fields": [ { "field": "*", "format": "date_time" } ]
}

Will return an error message like

error fetching [foo] which matches [*]: [keyword] doesn't support formats

It also centralizes the code adding the error fetching [foo] bit of
the error message so we don't have to be super duper careful to make
sure the field name comes back.

This adds the pattern into the error message returned when trying to
fetch fields. So this:
```
POST _search {
  "fields": [ { "field": "*", "format": "date_time" } ]
}
```

Will return an error message like
```
error fetching [foo] which matches [*]: [keyword] doesn't support formats
```

It also centralizes the code adding the `error fetching [foo]` bit of
the error message so we don't have to be super duper careful to make
sure the field name comes back.
@nik9000 nik9000 added >non-issue :Search/Search Search-related issues that do not fall into other categories v8.0.0-alpha1 v7.16.0 labels Aug 24, 2021
@elasticmachine elasticmachine added the Team:Search Meta label for search team label Aug 24, 2021
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search (Team:Search)

@nik9000
Copy link
Member Author

nik9000 commented Aug 24, 2021

I was debugging an issue this morning where folks were getting this error while requesting dozens of fields and I wanted to get a little help figuring out which of the fields in their request was the culprit. Without this change I had to manually rerun the matches in my head on the whole request. With this change it would have just told me which entry was suspect.

Copy link
Contributor

@ywelsch ywelsch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've left a suggestion for further refactoring, and I think we should keep the field name in the inner exception, even if that makes the combined message a bit more verbose than it needs to be.

if (isWildcardPattern) {
error.append(" which matched [").append(fieldAndFormat.field).append(']');
}
error.append(": ").append(e.getMessage());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a fan of piecing exception messages together in this way (in particular because IllegalArgumentException is a generic exception).

Also, it's unclear to me how the change in this PR will affect other call sites of the valueFetcher method (those will now not return the field name anymore and might be less precise / harder to debug).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I were running this in production myself I wouldn't do it, no. But I think its useful because we drop the getMessage() from the top level cause into the reason field of the error by default. I really care that the reason describes exactly what failed here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

About the other call sites - I believe there is only one non-test call that doesn't flow through here and it is in highlighting which calls the method in a way that won't throw. But the method is public and, who knows, highlighting may throw. I'll revert this and be happy with the more verbose message. It isn't worth that change.

@@ -57,7 +57,7 @@ public Query termQuery(Object value, SearchExecutionContext context) {
@Override
public ValueFetcher valueFetcher(SearchExecutionContext context, String format) {
if (format != null) {
throw new IllegalArgumentException("Field [" + name() + "] of type [" + typeName() + "] doesn't support formats.");
throw new IllegalArgumentException("[" + typeName() + "] doesn't support formats.");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check looks the same everywhere. How about factoring it out into its own method, e.g. checkNoFormats(format) in MappedFieldType that can be called in all these methods.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

++

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fieldContexts.put(field, new FieldContext(field, valueFetcher));
try {
ValueFetcher valueFetcher = ft.valueFetcher(context, fieldAndFormat.format);
fieldContexts.put(field, new FieldContext(field, valueFetcher));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's put the try catch only around the valueFetcher method

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure.

@nik9000
Copy link
Member Author

nik9000 commented Aug 26, 2021

I think we should keep the field name in the inner exception, even if that makes the combined message a bit more verbose than it needs to be.

I think after having removed them all I think I've come around to your way of thinking - more verbose is fine here. I'll undo that.

Copy link
Member

@cbuescher cbuescher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This look good to me after the recent changes but I would like to hear from @ywelsch to see if they adress his previous comments.

Copy link
Contributor

@ywelsch ywelsch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@nik9000 nik9000 merged commit dde7d41 into elastic:master Sep 1, 2021
@elasticsearchmachine
Copy link
Collaborator

💔 Backport failed

Status Branch Result
7.x Commit could not be cherrypicked due to conflicts

To backport manually run backport --upstream elastic/elasticsearch --pr 76903

nik9000 added a commit to nik9000/elasticsearch that referenced this pull request Sep 2, 2021
This adds the pattern into the error message returned when trying to
fetch fields. So this:
```
POST _search {
  "fields": [ { "field": "*", "format": "date_time" } ]
}
```

Will return an error message like
```
error fetching [foo] which matches [*]: Field [foo] of type [keyword] doesn't support formats
```
@nik9000
Copy link
Member Author

nik9000 commented Sep 2, 2021

Backport is here: #77191 . After backport I'll need bump the skip versions too.

nik9000 added a commit that referenced this pull request Sep 2, 2021
This adds the pattern into the error message returned when trying to
fetch fields. So this:
```
POST _search {
  "fields": [ { "field": "*", "format": "date_time" } ]
}
```

Will return an error message like
```
error fetching [foo] which matches [*]: Field [foo] of type [keyword] doesn't support formats
```
nik9000 added a commit to nik9000/elasticsearch that referenced this pull request Sep 2, 2021
Now that we've backported elastic#76903 we can run backwards compatibility
tests against all versions that have it.
nik9000 added a commit that referenced this pull request Sep 3, 2021
Now that we've backported #76903 we can run backwards compatibility
tests against all versions that have it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>non-issue :Search/Search Search-related issues that do not fall into other categories Team:Search Meta label for search team v7.16.0 v8.0.0-alpha1 v8.0.0-alpha2
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants