Elasticsearch NumberFormatException when running two consecutive java tests

Question

I have two test in a class, each of them containing the following query:

SearchQuery searchQuery = new NativeSearchQueryBuilder().withQuery(matchAllQuery()).withFilter(rangeFilter("publishDate").lt(date)).build();

In one of the tests, the number of the results elasticsearchTemplate.count(searchQuery, Article.class), in the other one the returned values are verified elasticsearchTemplate.queryForPage(searchQuery,Article.class)

If I run any of these two tests separately, the tests always pass, everything seems to work perfectly. If I run both of the two tests consequently, one after the other, the first one passes, the other one fails with a SearchPhaseExecutionException: Failed to execute phase ... nested: NumberFormatException[For input string: "2015-02-01T00:02:02.396Z"]...

It's even more strange, that this behavior appears just when a rangefilter for publishDate (having type: FieldType.Date) is applied. When other similar queries with boolFilter, termFilter etc are applied consequently, all the tests pass.

Also, if I run these two queries inside the same method: no exception is thrown.

I thought that an improper cache initialization/cleanup might cause the behavior... but still, why does not happen to the other queries as well?

Also, in the @After method of the class I delete all the indexes (elasticsearchTemplate.deleteIndex(Article.class)), and in the @Before method I do/redo bulk indexing and refresh.

Am I on the wrong path? What am I missing here?

The full stack trace:

org.elasticsearch.action.search.SearchPhaseExecutionException: Failed to execute phase [dfs], all shards failed; shardFailures {[jCBsPj2yR3qkX6HxN_xr4w][articles][0]: SearchParseException[[articles][0]: query[ConstantScore(*:*)],from[0],size[10]: Parse Failure [Failed to parse source [{"from":0,"size":10,"query":{"match_all":{}},"post_filter":{"range":{"publishDate":{"from":null,"to":"2015-02-01T00:02:02.676Z","include_lower":true,"include_upper":false}}}}]]]; nested: NumberFormatException[For input string: "2015-02-01T00:02:02.676Z"]; }{[jCBsPj2yR3qkX6HxN_xr4w][articles][1]: SearchParseException[[articles][1]: query[ConstantScore(*:*)],from[0],size[10]: Parse Failure [Failed to parse source [{"from":0,"size":10,"query":{"match_all":{}},"post_filter":{"range":{"publishDate":{"from":null,"to":"2015-02-01T00:02:02.676Z","include_lower":true,"include_upper":false}}}}]]]; nested: NumberFormatException[For input string: "2015-02-01T00:02:02.676Z"]; }{[jCBsPj2yR3qkX6HxN_xr4w][articles][2]: SearchParseException[[articles][2]: query[ConstantScore(*:*)],from[0],size[10]: Parse Failure [Failed to parse source [{"from":0,"size":10,"query":{"match_all":{}},"post_filter":{"range":{"publishDate":{"from":null,"to":"2015-02-01T00:02:02.676Z","include_lower":true,"include_upper":false}}}}]]]; nested: NumberFormatException[For input string: "2015-02-01T00:02:02.676Z"]; }{[jCBsPj2yR3qkX6HxN_xr4w][articles][3]: SearchParseException[[articles][3]: query[ConstantScore(*:*)],from[0],size[10]: Parse Failure [Failed to parse source [{"from":0,"size":10,"query":{"match_all":{}},"post_filter":{"range":{"publishDate":{"from":null,"to":"2015-02-01T00:02:02.676Z","include_lower":true,"include_upper":false}}}}]]]; nested: NumberFormatException[For input string: "2015-02-01T00:02:02.676Z"]; }{[jCBsPj2yR3qkX6HxN_xr4w][articles][4]: SearchParseException[[articles][4]: query[ConstantScore(*:*)],from[0],size[10]: Parse Failure [Failed to parse source [{"from":0,"size":10,"query":{"match_all":{}},"post_filter":{"range":{"publishDate":{"from":null,"to":"2015-02-01T00:02:02.676Z","include_lower":true,"include_upper":false}}}}]]]; nested: NumberFormatException[For input string: "2015-02-01T00:02:02.676Z"]; }
at org.elasticsearch.action.search.type.TransportSearchTypeAction$BaseAsyncAction.onFirstPhaseResult(TransportSearchTypeAction.java:238)
at org.elasticsearch.action.search.type.TransportSearchTypeAction$BaseAsyncAction$1.onFailure(TransportSearchTypeAction.java:184)
at org.elasticsearch.search.action.SearchServiceTransportAction$23.run(SearchServiceTransportAction.java:565)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)

The mapping for the article index:

@Document(indexName = "articles", type = "article", shards = 1, replicas = 0, refreshInterval = "-1", indexStoreType = "memory")
public class Article {
@Id
private Long id;
@Field(type = FieldType.String, store = true)
private String title;
@Field(type = FieldType.String, store = true)
private String text;
@Field(type = FieldType.String, store = true)
private String author;
@Field(type = FieldType.Date, store = true)
private Date publishDate;
@Field(type = FieldType.Date, store = true)
private Date lastModificationDate;
....
}

Answer 1

Since the exception complains about a NumberFormatException, you should try sending the date as a long (instead of a Date object) since this is how dates are stored internally. See I'm calling date.getTime() in the code below:

SearchQuery searchQuery = new NativeSearchQueryBuilder()
    .withQuery(matchAllQuery())
    .withFilter(rangeFilter("publishDate").lt(date.getTime())).build();

Answer 2

I found an other solution too.

In @Before method I had no explicit mapping applied, which means that the @Field annotations from the Article index were not considered. Practically, a default mapping was used.

By adding an explicit mapping:

elasticsearchTemplate.putMapping(Article.class)

the type for publishDate is taken from the index definition:

@Field(type = FieldType.Date, store = true)
private Date publishDate;

In this way all the tests pass, whether running them each individually or all of them sequentially.

Also, the rangeFilterparameter works fine with the initial date type too. (Sure, it works with long type as well.)