Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Sporadic failure in testForceStaleReplicaToBePromotedToPrimary #35497

Closed
DaveCTurner opened this issue Nov 13, 2018 · 2 comments · Fixed by #35728
Closed

Sporadic failure in testForceStaleReplicaToBePromotedToPrimary #35497

DaveCTurner opened this issue Nov 13, 2018 · 2 comments · Fixed by #35728
Assignees
@vladimirdolzhenko
Labels
:Distributed/Recovery Anything around constructing a new shard, either from a local or a remote source. >test-failure Triaged test failures from CI

Comments

@DaveCTurner
Copy link
Contributor

#34140 introduces an assertion in PrimaryAllocationIT#testForceStaleReplicaToBePromotedToPrimary that sometimes fails. See for instance https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+multijob-unix-compatibility/os=fedora/56/console:

   > Throwable #1: java.lang.AssertionError: expected:<[]> but was:<[tuWXzhckTEu0-GBybc-VJQ]>
   > 	at __randomizedtesting.SeedInfo.seed([6DA82B0AC7639B17:3BB0A62AD8D3F5B0]:0)
   > 	at org.elasticsearch.cluster.routing.PrimaryAllocationIT.testForceStaleReplicaToBePromotedToPrimary(PrimaryAllocationIT.java:222)
   > 	at java.lang.Thread.run(Thread.java:748)

I think the issue is that we allocate a stale or empty primary via a reroute command, then grab the cluster state, and then assert that the in-sync IDs in that cluster state are what they should be straight after the reroute. However, if the shard has actually been allocated by the time we get hold of the cluster state then this assertion fails.

@vladimirdolzhenko could you take a look?
@DaveCTurner DaveCTurner added >test-failure Triaged test failures from CI :Distributed/Recovery Anything around constructing a new shard, either from a local or a remote source. labels Nov 13, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed

@vladimirdolzhenko vladimirdolzhenko self-assigned this Nov 13, 2018
@vladimirdolzhenko vladimirdolzhenko mentioned this issue Nov 20, 2018
Merged
@vladimirdolzhenko
Copy link
Contributor

Closed with #35728

@alpar-t alpar-t mentioned this issue Jan 11, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@vladimirdolzhenko vladimirdolzhenko

Labels
:Distributed/Recovery Anything around constructing a new shard, either from a local or a remote source. >test-failure Triaged test failures from CI
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix PrimaryAllocationIT#testForceStaleReplicaToBePromotedToPrimary vladimirdolzhenko/elasticsearch
4 participants
@vladimirdolzhenko @DaveCTurner @elasticmachine and others