Error handling for HTTP search API

I have an application allowing users to specify the "query" value of a
"query_string" query. If the user inputs invalid search syntax, e.g. their
search is only "AND" (an operator without any values), Elasticsearch
returns an exceedingly verbose error message with very user-unfriendly
text like "failed to execute phase" and "shard failure", when what I really
want is a simple user-friendly error like "Bad search syntax". In this
particular example, text within the "QueryParsingException" sections is
close to what I'm looking for.

QueryParsingException[[<index_name>] Failed to parse query [AND]]

But it's buried in a sea of text. I could parse out any text within the
QueryParsingException, but frankly that feels like reverse-engineering.
Will all queries with bad syntax have user-friendly error text like this
particular example? Is the most user-friendly message always likely to
appear within QueryParsingException? Are there other error scenarios I
might want to handle that don't even have a QueryParsingException?

I've been digging through Elasticsearch documentation for some explanation
of the kinds of errors I might expect and what format those error messages
will be in, but I'm coming up blank. For what it's worth, I'm integrating
using the .NET client NEST.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/

You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Try simple_query_string.

BTW we moved to https://discuss.elastic.co/

David

Le 7 mai 2015 à 06:56, Snixtor snixtor@gmail.com a écrit :

I have an application allowing users to specify the "query" value of a "query_string" query. If the user inputs invalid search syntax, e.g. their search is only "AND" (an operator without any values), Elasticsearch returns an exceedingly verbose error message with very user-unfriendly text like "failed to execute phase" and "shard failure", when what I really want is a simple user-friendly error like "Bad search syntax". In this particular example, text within the "QueryParsingException" sections is close to what I'm looking for.

QueryParsingException[[<index_name>] Failed to parse query [AND]]

But it's buried in a sea of text. I could parse out any text within the QueryParsingException, but frankly that feels like reverse-engineering. Will all queries with bad syntax have user-friendly error text like this particular example? Is the most user-friendly message always likely to appear within QueryParsingException? Are there other error scenarios I might want to handle that don't even have a QueryParsingException?

I've been digging through Elasticsearch documentation for some explanation of the kinds of errors I might expect and what format those error messages will be in, but I'm coming up blank. For what it's worth, I'm integrating using the .NET client NEST.

Please update your bookmarks! We moved to https://discuss.elastic.co/

You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/

You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/8326F3E5-FE75-41A8-B6DA-6DF79B5BC7AB%40pilato.fr.
For more options, visit https://groups.google.com/d/optout.

Regarding the discussion forum, I noticed literally 1 minute after posting
this message. Should I duplicate this question in the forum? Can it be
moved from the discussion group into the forum? The "we have moved" FAQ
didn't address this matter of "transition".

Regarding simple_query_string, I'm not as fond of the syntax. My
application is transitioning from another text search system to
Elasticsearch, and the syntax of query_string is a closer match to what
users are familiar with. For example, query_string uses "AND", while
simple_query_string uses "+". For the user base, that's possibly a bigger issue
than big error messages.

On Thursday, 7 May 2015 15:01:55 UTC+10, David Pilato wrote:

Try simple_query_string.

BTW we moved to https://discuss.elastic.co/

David

Le 7 mai 2015 à 06:56, Snixtor <sni...@gmail.com <javascript:>> a écrit :

I have an application allowing users to specify the "query" value of a
"query_string" query. If the user inputs invalid search syntax, e.g. their
search is only "AND" (an operator without any values), Elasticsearch
returns an exceedingly verbose error message with very user-unfriendly
text like "failed to execute phase" and "shard failure", when what I really
want is a simple user-friendly error like "Bad search syntax". In this
particular example, text within the "QueryParsingException" sections is
close to what I'm looking for.

QueryParsingException[[<index_name>] Failed to parse query [AND]]

But it's buried in a sea of text. I could parse out any text within the
QueryParsingException, but frankly that feels like reverse-engineering.
Will all queries with bad syntax have user-friendly error text like
this particular example? Is the most user-friendly message always likely to
appear within QueryParsingException? Are there other error scenarios I
might want to handle that don't even have a QueryParsingException?

I've been digging through Elasticsearch documentation for some explanation
of the kinds of errors I might expect and what format those error messages
will be in, but I'm coming up blank. For what it's worth, I'm integrating
using the .NET client NEST.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/

You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearc...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/

You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

No that's fine to keep this thread here.
Well with query_string you can also use +

I did not check but I think that AND might work as well with simple query string. It's not?

David

Le 7 mai 2015 à 07:14, Snixtor snixtor@gmail.com a écrit :

Regarding the discussion forum, I noticed literally 1 minute after posting this message. Should I duplicate this question in the forum? Can it be moved from the discussion group into the forum? The "we have moved" FAQ didn't address this matter of "transition".

Regarding simple_query_string, I'm not as fond of the syntax. My application is transitioning from another text search system to Elasticsearch, and the syntax of query_string is a closer match to what users are familiar with. For example, query_string uses "AND", while simple_query_string uses "+". For the user base, that's possibly a bigger issue than big error messages.

On Thursday, 7 May 2015 15:01:55 UTC+10, David Pilato wrote:
Try simple_query_string.

BTW we moved to https://discuss.elastic.co/

David

Le 7 mai 2015 à 06:56, Snixtor sni...@gmail.com a écrit :

I have an application allowing users to specify the "query" value of a "query_string" query. If the user inputs invalid search syntax, e.g. their search is only "AND" (an operator without any values), Elasticsearch returns an exceedingly verbose error message with very user-unfriendly text like "failed to execute phase" and "shard failure", when what I really want is a simple user-friendly error like "Bad search syntax". In this particular example, text within the "QueryParsingException" sections is close to what I'm looking for.

QueryParsingException[[<index_name>] Failed to parse query [AND]]

But it's buried in a sea of text. I could parse out any text within the QueryParsingException, but frankly that feels like reverse-engineering. Will all queries with bad syntax have user-friendly error text like this particular example? Is the most user-friendly message always likely to appear within QueryParsingException? Are there other error scenarios I might want to handle that don't even have a QueryParsingException?

I've been digging through Elasticsearch documentation for some explanation of the kinds of errors I might expect and what format those error messages will be in, but I'm coming up blank. For what it's worth, I'm integrating using the .NET client NEST.

Please update your bookmarks! We moved to https://discuss.elastic.co/

You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/

You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/

You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr.
For more options, visit https://groups.google.com/d/optout.

"I think that AND might work as well with simple query string"

Tried just now. Doesn't work, it gets treated as a search term instead of
an operator, so is functionally equivalent to "and" in query_string. I
could try translating operators, but a truly robust implementation of
that is more work than I would have liked.

On 7 May 2015 at 15:35, David Pilato david@pilato.fr wrote:

No that's fine to keep this thread here.
Well with query_string you can also use +

I did not check but I think that AND might work as well with simple query
string. It's not?

David

Le 7 mai 2015 à 07:14, Snixtor snixtor@gmail.com a écrit :

Regarding the discussion forum, I noticed literally 1 minute after posting
this message. Should I duplicate this question in the forum? Can it be
moved from the discussion group into the forum? The "we have moved" FAQ
didn't address this matter of "transition".

Regarding simple_query_string, I'm not as fond of the syntax. My
application is transitioning from another text search system to
Elasticsearch, and the syntax of query_string is a closer match to what
users are familiar with. For example, query_string uses "AND", while
simple_query_string uses "+". For the user base, that's possibly a
bigger issue than big error messages.

On Thursday, 7 May 2015 15:01:55 UTC+10, David Pilato wrote:

Try simple_query_string.

BTW we moved to https://discuss.elastic.co/

David

Le 7 mai 2015 à 06:56, Snixtor sni...@gmail.com a écrit :

I have an application allowing users to specify the "query" value of a
"query_string" query. If the user inputs invalid search syntax, e.g. their
search is only "AND" (an operator without any values), Elasticsearch
returns an exceedingly verbose error message with very user-unfriendly
text like "failed to execute phase" and "shard failure", when what I really
want is a simple user-friendly error like "Bad search syntax". In this
particular example, text within the "QueryParsingException" sections is
close to what I'm looking for.

QueryParsingException[[<index_name>] Failed to parse query [AND]]

But it's buried in a sea of text. I could parse out any text within the
QueryParsingException, but frankly that feels like reverse-engineering.
Will all queries with bad syntax have user-friendly error text like
this particular example? Is the most user-friendly message always likely to
appear within QueryParsingException? Are there other error scenarios I
might want to handle that don't even have a QueryParsingException?

I've been digging through Elasticsearch documentation for some
explanation of the kinds of errors I might expect and what format those
error messages will be in, but I'm coming up blank. For what it's worth,
I'm integrating using the .NET client NEST.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/

You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearc...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/


You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/

You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/CSmm9zdw1dM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr
https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/

You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CANsC95qnEtcfTORTs%3DFq-qSuHFn3-eeEiv2UC36HLq12eHsv1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Indeed. The only workaround I can see in addition to the one you found with + is to set default_operator to AND

DELETE simple
PUT simple/test/1
{
"foo": "bar baz"
}
PUT simple/test/2
{
"foo": "bar boz"
}
GET simple/_search
{
"query": {
"simple_query_string": {
"query": "bar baz",
"fields": [ "foo" ],
"default_operator": "AND"
}
}
}

But that’s not exactly what you are looking for.

--
David Pilato - Developer | Evangelist

@dadoonet https://twitter.com/dadoonet | @elasticsearchfr https://twitter.com/elasticsearchfr | @scrutmydocs https://twitter.com/scrutmydocs

Le 7 mai 2015 à 07:41, Jason snixtor@gmail.com a écrit :

"I think that AND might work as well with simple query string"

Tried just now. Doesn't work, it gets treated as a search term instead of an operator, so is functionally equivalent to "and" in query_string. I could try translating operators, but a truly robust implementation of that is more work than I would have liked.

On 7 May 2015 at 15:35, David Pilato <david@pilato.fr mailto:david@pilato.fr> wrote:
No that's fine to keep this thread here.
Well with query_string you can also use +

I did not check but I think that AND might work as well with simple query string. It's not?

David

Le 7 mai 2015 à 07:14, Snixtor <snixtor@gmail.com mailto:snixtor@gmail.com> a écrit :

Regarding the discussion forum, I noticed literally 1 minute after posting this message. Should I duplicate this question in the forum? Can it be moved from the discussion group into the forum? The "we have moved" FAQ didn't address this matter of "transition".

Regarding simple_query_string, I'm not as fond of the syntax. My application is transitioning from another text search system to Elasticsearch, and the syntax of query_string is a closer match to what users are familiar with. For example, query_string uses "AND", while simple_query_string uses "+". For the user base, that's possibly a bigger issue than big error messages.

On Thursday, 7 May 2015 15:01:55 UTC+10, David Pilato wrote:
Try simple_query_string.

BTW we moved to https://discuss.elastic.co/ https://discuss.elastic.co/

David

Le 7 mai 2015 à 06:56, Snixtor <sni...@gmail.com <>> a écrit :

I have an application allowing users to specify the "query" value of a "query_string" query. If the user inputs invalid search syntax, e.g. their search is only "AND" (an operator without any values), Elasticsearch returns an exceedingly verbose error message with very user-unfriendly text like "failed to execute phase" and "shard failure", when what I really want is a simple user-friendly error like "Bad search syntax". In this particular example, text within the "QueryParsingException" sections is close to what I'm looking for.

QueryParsingException[[<index_name>] Failed to parse query [AND]]

But it's buried in a sea of text. I could parse out any text within the QueryParsingException, but frankly that feels like reverse-engineering. Will all queries with bad syntax have user-friendly error text like this particular example? Is the most user-friendly message always likely to appear within QueryParsingException? Are there other error scenarios I might want to handle that don't even have a QueryParsingException?

I've been digging through Elasticsearch documentation for some explanation of the kinds of errors I might expect and what format those error messages will be in, but I'm coming up blank. For what it's worth, I'm integrating using the .NET client NEST.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/ https://discuss.elastic.co/

You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearc...@googlegroups.com <>.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/ https://discuss.elastic.co/

You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com mailto:elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/ https://discuss.elastic.co/

You received this message because you are subscribed to a topic in the Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elasticsearch/CSmm9zdw1dM/unsubscribe https://groups.google.com/d/topic/elasticsearch/CSmm9zdw1dM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elasticsearch+unsubscribe@googlegroups.com mailto:elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr?utm_medium=email&utm_source=footer.

For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/ https://discuss.elastic.co/

You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com mailto:elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CANsC95qnEtcfTORTs%3DFq-qSuHFn3-eeEiv2UC36HLq12eHsv1Q%40mail.gmail.com https://groups.google.com/d/msgid/elasticsearch/CANsC95qnEtcfTORTs%3DFq-qSuHFn3-eeEiv2UC36HLq12eHsv1Q%40mail.gmail.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/

You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/1C955DCD-6E33-443D-8292-2FD79ADCC567%40pilato.fr.
For more options, visit https://groups.google.com/d/optout.

Indeed. Even if I did tinker with these alternative query styles to avoid
syntax errors, there's other error scenarios to consider. What kind of
message and error structure could I expect for, say, a critical shard
failure? I'd still really like to know:

  1. What kind of error reports I can expect, and;
  2. What structure those reports will have.

I look at, say, C# .NET, where every library method has a clear definition
of what exception objects to expect, and in what scenarios. The
strongly-typed exception objects make it easy to gracefully handle
different errors -
File.Open Method (System.IO) | Microsoft Learn - If on
File.Open I get a FileNotFoundException, I can probably blame the user for
choosing an invalid file name. But if I get an IOException, I can probably
say "oh no, I think there might be a problem with your disk".

Or the Twitter REST API where response codes are all clearly defined within
the context of the API - Documentation Home | Docs | Twitter Developer Platform
The Twitter advertising API even has the good grace to provide an
errors/message node that *"will indicate a (usually) human-readable
description of the error in English" *-
https://dev.twitter.com/ads/campaigns/response-codes

But I can't find any equivalent documentation for Elasticsearch. The
closest I've come so far is this -

  • "Elasticsearch returns an HTTP status code like 200 OK". From which I
    might assume a full range of HTTP status codes is in use. But... y'know,
    assumptions. And even with HTTP status codes, unless there's an
    accompanying (concise) message, it's not easy to determine what's going on.
    A 400 - Bad Request could mean bad query syntax, or it could mean the query
    is specifying an index that doesn't exist. As an integrating application,
    it would be my responsibility to notify the user that they've entered a
    bad query, but it might be my responsibility to notify an admin in the
    case of a missing index.

On 8 May 2015 at 01:03, David Pilato david@pilato.fr wrote:

Indeed. The only workaround I can see in addition to the one you found
with + is to set default_operator to AND

DELETE simple
PUT simple/test/1
{
"foo": "bar baz"
}
PUT simple/test/2
{
"foo": "bar boz"
}
GET simple/_search
{
"query": {
"simple_query_string": {
"query": "bar baz",
"fields": [ "foo" ],
"default_operator": "AND"
}
}
}

But that’s not exactly what you are looking for.

--
David Pilato - Developer | Evangelist
elastic.co http://elastic.co
@dadoonet https://twitter.com/dadoonet | @elasticsearchfr
https://twitter.com/elasticsearchfr | @scrutmydocs
https://twitter.com/scrutmydocs

Le 7 mai 2015 à 07:41, Jason snixtor@gmail.com a écrit :

"I think that AND might work as well with simple query string"

Tried just now. Doesn't work, it gets treated as a search term instead of
an operator, so is functionally equivalent to "and" in query_string. I
could try translating operators, but a truly robust implementation of
that is more work than I would have liked.

On 7 May 2015 at 15:35, David Pilato david@pilato.fr wrote:

No that's fine to keep this thread here.
Well with query_string you can also use +

I did not check but I think that AND might work as well with simple query
string. It's not?

David

Le 7 mai 2015 à 07:14, Snixtor snixtor@gmail.com a écrit :

Regarding the discussion forum, I noticed literally 1 minute after
posting this message. Should I duplicate this question in the forum? Can it
be moved from the discussion group into the forum? The "we have moved" FAQ
didn't address this matter of "transition".

Regarding simple_query_string, I'm not as fond of the syntax. My
application is transitioning from another text search system to
Elasticsearch, and the syntax of query_string is a closer match to what
users are familiar with. For example, query_string uses "AND", while
simple_query_string uses "+". For the user base, that's possibly a
bigger issue than big error messages.

On Thursday, 7 May 2015 15:01:55 UTC+10, David Pilato wrote:

Try simple_query_string.

BTW we moved to https://discuss.elastic.co/

David

Le 7 mai 2015 à 06:56, Snixtor sni...@gmail.com a écrit :

I have an application allowing users to specify the "query" value of a
"query_string" query. If the user inputs invalid search syntax, e.g. their
search is only "AND" (an operator without any values), Elasticsearch
returns an exceedingly verbose error message with very
user-unfriendly text like "failed to execute phase" and "shard failure",
when what I really want is a simple user-friendly error like "Bad search
syntax". In this particular example, text within the
"QueryParsingException" sections is close to what I'm looking for.

QueryParsingException[[<index_name>] Failed to parse query [AND]]

But it's buried in a sea of text. I could parse out any text within the
QueryParsingException, but frankly that feels like reverse-engineering. Will
all queries with bad syntax have user-friendly error text like this
particular example? Is the most user-friendly message always likely to
appear within QueryParsingException? Are there other error scenarios I
might want to handle that don't even have a QueryParsingException?

I've been digging through Elasticsearch documentation for some
explanation of the kinds of errors I might expect and what format those
error messages will be in, but I'm coming up blank. For what it's worth,
I'm integrating using the .NET client NEST.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/

You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearc...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/

You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/

You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/CSmm9zdw1dM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr
https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/

You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/CANsC95qnEtcfTORTs%3DFq-qSuHFn3-eeEiv2UC36HLq12eHsv1Q%40mail.gmail.com
https://groups.google.com/d/msgid/elasticsearch/CANsC95qnEtcfTORTs%3DFq-qSuHFn3-eeEiv2UC36HLq12eHsv1Q%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/

You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/CSmm9zdw1dM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/1C955DCD-6E33-443D-8292-2FD79ADCC567%40pilato.fr
https://groups.google.com/d/msgid/elasticsearch/1C955DCD-6E33-443D-8292-2FD79ADCC567%40pilato.fr?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
Please update your bookmarks! We moved to https://discuss.elastic.co/

You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CANsC95qOv5W%2BKJzhUTdHO49AQ8490ETcEiL3da6bQws5MG8eCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

So I'm still none-the-wiser. It feels like this is a notable omission in
the Elasticsearch implementation. I want to implement more graceful error
handling for my Elasticsearch integration, but the means don't seem to be
available. Is this the case? The deeper I consider the situation, the
further it goes beyond simple query validation, that's just a single simple
example.

Scenario:

  1. User sends a query to my application.
  2. My application sends the query to ES.
  3. ES returns an error to my application.
  4. My application processes detail of the error and provides a suitable
    message to the user, such as:
    a) Your query was badly formed, try again.
    b) The index doesn't exist.
    c) The iron-man node is failing.
    d) The server is on fire, please call 911.

But I can't do this, because I can't find any specification of the types of
error messages that ES might return, or what structure they are in so I can
reliably parse the content. How do I know the error message won't come back
in XML, or even image/jpeg? I know that's an absurd example, but without
spec...

--
Please update your bookmarks! We have moved to https://discuss.elastic.co/

You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/595e377a-0f58-4111-b860-b0f854c66526%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.