Files
nats-server/server
Derek Collison 783edaa36d [FIXED] Race condition in some leader failover scenarios leading to messages being potentially sourced more than once. (#4592)
- [X] Tests added
- [X] Branch rebased on top of current main (`git pull --rebase origin
main`)
- [X] Changes squashed to a single commit (described
[here](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html))
 - [x] Build is green in Travis CI
- [X] You have certified that the contribution is your original work and
that you license the work to the project under the [Apache 2
license](https://github.com/nats-io/nats-server/blob/main/LICENSE)

### Changes proposed in this pull request:

Fixes a race condition in some leader failover scenarios leading to
messages being potentially sourced more than once.

In some failure scenarios where the current leader of a stream sourcing
from other stream(s) gets shutdown while publications are happening on
the stream(s) being sourced leads to `setLeader(true)` being called on
the new leader for the sourcing stream before all the messages having
been sourced by the previous leader are completely processed such that
when the new leader does it's reverse scan from the last message in it's
view of the stream in order to know what sequence number to start the
consumer for the stream being sourced from, such that the last
message(s) sourced by the previous leader get sourced again, leading to
some messages being sourced more than once.

The existing `TestNoRaceJetStreamSuperClusterSources` test would
sidestep the issue by relying on the deduplication window in the
sourcing stream. Without deduplication the test is a flapper.

This avoid the race condition by adding a small delay before scanning
for the last message(s) having been sourced and starting the sources'
consumer(s). Now the test (without using the deduplication window) never
fails because more messages than expected have been received in the
sourcing stream.

(Also adds a guard to give up if `setupSourceConsumers()` is called and
we are no longer the leader for the stream (that check was already
present in `setupMirrorConsumer()` so assuming it was forgotten for
`setupSourceConsumers()`)
2023-09-28 11:22:20 -07:00
..
2023-08-02 11:25:48 -07:00
2023-07-18 12:21:31 -07:00
2023-06-03 10:03:23 +05:30
2023-09-27 20:49:55 -07:00
2023-06-02 13:19:22 +03:00
2023-07-21 16:56:13 -07:00
2023-08-30 14:54:30 -07:00
2023-08-02 11:25:48 -07:00
2023-08-04 10:15:35 -07:00
2023-04-12 11:48:22 -07:00
2023-01-17 17:40:39 -08:00
2022-12-27 09:41:39 +01:00

Tests

Tests that run on Travis have been split into jobs that run in their own VM in parallel. This reduces the overall running time but also is allowing recycling of a job when we get a flapper as opposed to have to recycle the whole test suite.

JetStream Tests

For JetStream tests, we need to observe a naming convention so that no tests are omitted when running on Travis.

The script runTestsOnTravis.sh will run a given job based on the definition found in ".travis.yml".

As for the naming convention:

  • All JetStream tests name should start with TestJetStream
  • Cluster tests should go into jetstream_cluster_test.go and start with TestJetStreamCluster
  • Super-cluster tests should go into jetstream_super_cluster_test.go and start with TestJetStreamSuperCluster

Not following this convention means that some tests may not be executed on Travis.