[CI] DedicatedClusterSnapshotRestoreIT.testMasterShutdownDuringSnapshot failure #51253
Assignees
Labels
:Distributed/Snapshot/Restore
Anything directly related to the `_snapshot/*` APIs
>test-failure
Triaged test failures from CI
Comments
andreidan
added
:Distributed/Snapshot/Restore
|
Pinging @elastic/es-distributed (:Distributed/Snapshot/Restore) |
andreidan
changed the title
|
Looks like this may have been introduced by #50788 ... will create a fix shortly |
original-brownbear
added a commit
to original-brownbear/elasticsearch
that referenced
this issue
Jan 21, 2020
On master failover we have to resent all the shard failed messages, but the transport requests remain the same in the eyes of `equals`. If the master failover is registered and the requests to the new master are sent before all the callbacks have executed and the request to the old master removed from the deduplicator then the requuests to the new master will incorrectly fail and the snapshot get stuck. Closes elastic#51253
original-brownbear
added a commit
that referenced
this issue
Jan 22, 2020
On master failover we have to resent all the shard failed messages, but the transport requests remain the same in the eyes of `equals`. If the master failover is registered and the requests to the new master are sent before all the callbacks have executed and the request to the old master removed from the deduplicator then the requuests to the new master will incorrectly fail and the snapshot get stuck. Closes #51253
original-brownbear
added a commit
to original-brownbear/elasticsearch
that referenced
this issue
Jan 22, 2020
On master failover we have to resent all the shard failed messages, but the transport requests remain the same in the eyes of `equals`. If the master failover is registered and the requests to the new master are sent before all the callbacks have executed and the request to the old master removed from the deduplicator then the requuests to the new master will incorrectly fail and the snapshot get stuck. Closes elastic#51253
original-brownbear
added a commit
to original-brownbear/elasticsearch
that referenced
this issue
Jan 22, 2020
On master failover we have to resent all the shard failed messages, but the transport requests remain the same in the eyes of `equals`. If the master failover is registered and the requests to the new master are sent before all the callbacks have executed and the request to the old master removed from the deduplicator then the requuests to the new master will incorrectly fail and the snapshot get stuck. Closes elastic#51253
original-brownbear
added a commit
that referenced
this issue
Jan 22, 2020
On master failover we have to resent all the shard failed messages, but the transport requests remain the same in the eyes of `equals`. If the master failover is registered and the requests to the new master are sent before all the callbacks have executed and the request to the old master removed from the deduplicator then the requuests to the new master will incorrectly fail and the snapshot get stuck. Closes #51253
original-brownbear
added a commit
that referenced
this issue
Jan 22, 2020
On master failover we have to resent all the shard failed messages, but the transport requests remain the same in the eyes of `equals`. If the master failover is registered and the requests to the new master are sent before all the callbacks have executed and the request to the old master removed from the deduplicator then the requuests to the new master will incorrectly fail and the snapshot get stuck. Closes #51253
This was referenced Feb 3, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Encountered this failure on a feature branch https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+pull-request-1/14196/
A build scan is available here https://gradle-enterprise.elastic.co/s/y3sp3pow27tp2
The text was updated successfully, but these errors were encountered: