-
Notifications
You must be signed in to change notification settings - Fork 25.2k
[CI] InternalAggregationsTests testSerialization reproducibly failing #50827
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
Comments
Pinging @elastic/es-search (:Search/Search) |
Looks like yet again a subtle time zone glitch, only triggered when the serialization is done on a version <7.0. The time zone of the |
When deserializing time zones in the Rounding classes we used to include a tiny normalization step via `DateUtils.of(in.readString())` that was lost in elastic#50609. Its at least necessary for some tests, e.g. the cause of elastic#50827 is that when sending the default time zone ZoneOffset.UTC on a stream pre 7.0 we convert it to a "UTC" string id via `DateUtils.zoneIdToDateTimeZone`. This gets then read back as a UTC ZoneRegion, which should behave the same but fails the equality tests in our serialization tests. Reverting to the previous behaviour with an additional normalization step on 7.x.
When deserializing time zones in the Rounding classes we used to include a tiny normalization step via `DateUtils.of(in.readString())` that was lost in #50609. Its at least necessary for some tests, e.g. the cause of #50827 is that when sending the default time zone ZoneOffset.UTC on a stream pre 7.0 we convert it to a "UTC" string id via `DateUtils.zoneIdToDateTimeZone`. This gets then read back as a UTC ZoneRegion, which should behave the same but fails the equality tests in our serialization tests. Reverting to the previous behaviour with an additional normalization step on 7.x. Co-authored-by: Nik Everett <[email protected]> Closes #50827
Should be closed by #50845 |
org.elasticsearch.search.aggregations.InternalAggregationsTests » testSerialization
has failed 7 times today and hasn't failed otherwise in the past month, so it's likely something is busted here.Here's a build failure for which the reproduction line reproduces locally for me: https://gradle-enterprise.elastic.co/s/jrqqlb4u4unv2/tests/nfxodyych4uas-dbj4whiivduzy
The text was updated successfully, but these errors were encountered: