`TemporalPropertyValueConverter` is called multiple times for Date `@Field` in Repository queries

[dadouam]

Hello,

I believe I have come across a regression between 4.2.0 and 4.3.0 of the spring-data-elasticsearch library.

Please find attached a zip file containing two sample projects: one in 4.2.0 and the other in 4.3.0. To run it, first launch docker-compose up (from either one of the folders) and then try to execute the single test.
demo-temporalpropertyvalueconverter.zip

The 4.2.0 test runs successfully, however the 4.3.0 runs into the following runtime exception:

Caused by: java.lang.ClassCastException: class java.lang.String cannot be cast to class java.time.temporal.TemporalAccessor (java.lang.String and java.time.temporal.TemporalAccessor are in module java.base of loader 'bootstrap')

Looking into the stack trace and adding breakpoints, it looks like the TemporalPropertyValueConverter#write() method is called more than it should. It is first called to convert the OffsetDateTime field to the specified @Field format, but then it is called again to try to convert the already-converted string (e.g 2021-11-30T16:21:04.927+01:00), causing a ClassCastException because a String is not a TemporalAccessor.

Moving up the debugger stack trace, it looks like that the MappingElasticsearchConverter#updateQuery method being called multiple times when executing Repository queries is what may be causing this issue?

I have not included the following test in the zip but Criteria queries (and Native ones) work fine:

	@Test
	void criteria() {
		testDocumentRepository.save(new TestDocument(UUID.randomUUID(), OffsetDateTime.now()));
		Query query = new CriteriaQuery(new Criteria("startDate").between(OffsetDateTime.now().minusDays(3), OffsetDateTime.now().plusDays(1)));
		SearchHits<TestDocument> hits = elasticsearchOperations.search(query, TestDocument.class);
		Assertions.assertThat(hits.getTotalHits()).isNotZero();
	}

Thanks

[sothawo]

Thanks for finding this. The problem is not that updateQuery is called twice, but that the PropertyValueConverter has changed (reimplemented in 4.3) and now did not check the compatibility of the type to convert before casting.
This has been fixed in the main branch and is backported to the 4.3.x branch.