Client shouldn't silently fail if index name is wrong

[mastoj]

When preparing for a demo I tried to name an index with a capital letter. It took me a while to figure out what was wrong since I didn't get any indicators that it was wrong.

Two solution as I see it:

1. Throw an exception if there is an uppercase letter in the index. (Does elasticsearch allow non english letters in the index name?)
2. Do a to lowercase on the index before creating it.

I would go for number one since it is more explicit and probably will guide the developers the right way.

[Mpdreamz]

It wont silently fail (.IsValid is still false) but we could/should totally throw an ArgumentException in this case.

There are a couple of rules to index names:

https://github.com/elasticsearch/elasticsearch/blob/65d40468b8020df812ce8637cee657ef865c0298/src/main/java/org/elasticsearch/cluster/metadata/MetaDataCreateIndexService.java#L155-L173

ditto with repository names and others that we could obey better in the client.

Will add first thing in the morning.

[mastoj]

Already added, see PR :)

Didn't check IsValid, but as you said, throwing an ArgumentException is probably a good thing to do here.

Didn't add any tests, cause I couldn't find where you had all the other non integration create index tests.

A simple test method should be something like

[TestCase("abC")]
[TestCase("aBc")]
[TestCase("Abc")]
[TestCase("ABC")]
public void CreateIndexShouldThrowIfNotOnlyLowercase(string indexName)
{
    Assert.Throws<ArgumentException>(() => client.CreateIndex(indexName));
}

[Mpdreamz]

Pulled it in but rewrote it to mimic elasticsearch's validation and moved the validation in an appropriate place where all the CreateIndex() overloads pass through.

https://github.com/elasticsearch/elasticsearch-net/blob/develop/src/Tests/Nest.Tests.Unit/Internals/Inferno/IndexNameResolverTests.cs

In general NEST favours error messages from the server but this is especially confusing to people completely new to NEST and elasticsearch that are just getting started.

@gmarz we could also move this validation to whenever an IndexNameMarker is resolved, way more aggressive but I'm leaning a bit towards yes, thoughts?

Thanks for reporting @mastoj 👍

[mastoj]

No probs. @Mpdreamz

[gmarz]

@Mpdreamz @mastoj

I'm leaning towards not throwing an exception here at all. While I see the benefits (failing early without making a trip to ES) this is technically an Elasticsearch exception and the responsibility of Elasticsearch to determine if an index name is valid. IMO it would be better to stay consistent with how we handle Elasticsearch exceptions everywhere else- that is IsValid = false and reporting back the exception (unless ThrowOnElasticsearchExceptions == true). This also adds extra maintenance to the client, as we'll have to keep our validation rules in line with ES in case they ever change.

Just my two cents. If you guys still feel strongly that NEST should validate and throw, then yea I would say IndexNameMarker would be a better place for this.

[Mpdreamz]

That has been my philosophy as well but thinking as someone completely new to elasticsearch and NEST will most likely name their indexes in PascalCase and then not know where to look for the answer in the response.

I feel in this case we should make an exception to the rule, will let it bake in my head over the weekend and perhaps see what the guys from the other clients think/do as well.

[mastoj]

I do agree with scenarios. It's always good to be consistent, but at the same time it sucks with failing when creating the index. The problem with the model as I see it now is that I don't think users look at the result when they are not querying, and that makes it hard to find these kinds of error since you write the Index request as:

client.Index(....)

At the same time, this is a rule in Elasticsearch and the rule should be there I think. Would it be possible to do the actual request for Index and then throw an exception if the request failed? I know this should not be done in general, but that might be a valid solution for the index case?

[Mpdreamz]

@gmarz where are you at with throwing an exception here?

I like @mastoj idea for throwing the exception when the request has failed but my vote still goes to doing clientside validation in this case. Elasticsearch only validates this on index creation as well and simply throws a 404 if you use an invalid index name later on.

[gmarz]

@Mpdreamz @mastoj I'm still a bit torn on how to handle this. While I completely get that it might be confusing for the user, I'm still leaning towards not throwing for a few reasons:

• It's inconsistent with how we handle Elasticsearch exceptions everywhere else.
• The client side validation now has to be kept in sync with the validation done in Elasticsearch. Given Define valid index, type, field, id, routing values elasticsearch#6736, it looks like these rules could change.

[gmarz]

@mastoj Just to keep you in the loop, we ended up deciding not to implement any client side validation for index names for the above reasons. We also checked with the other clients, and confirmed that they also do not do any validation of this sort.

[mastoj]

Ok. Might be a good decision in the long run.

-----Original Message-----
From: "Greg Marzouka" notifications@github.com
Sent: ‎24.‎11.‎2014 21:53
To: "elasticsearch/elasticsearch-net" elasticsearch-net@noreply.github.com
Cc: "Tomas Jansson" tomas.jansson@gmail.com
Subject: Re: [elasticsearch-net] Client shouldn't silently fail if index nameis wrong (#1017)

@mastoj Just to keep you in the loop, we ended up deciding not to implement any client side validation for index names for the above reasons. We also checked with the other clients, and confirmed that they also do not do any validation of this sort.
—
Reply to this email directly or view it on GitHub.=