Tarantool development patches archive
 help / color / mirror / Atom feed
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
To: Serge Petrenko <sergepetrenko@tarantool.org>,
	tarantool-patches@dev.tarantool.org, avtikhon@tarantool.org
Subject: Re: [Tarantool-patches] [PATCH 2/2] raft: fix crash on candidate cfg during WAL write
Date: Mon, 9 Nov 2020 23:42:12 +0100	[thread overview]
Message-ID: <043d73e1-9a87-12e6-c09f-f977beffc6f8@tarantool.org> (raw)
In-Reply-To: <a527f42c-664f-f945-5cfa-f7ca459cba65@tarantool.org>

Thanks for the review!

>> diff --git a/test/replication/gh-5506-election-on-off.result b/test/replication/gh-5506-election-on-off.result
>> index 1a718396f..4fbc31986 100644
>> --- a/test/replication/gh-5506-election-on-off.result
>> +++ b/test/replication/gh-5506-election-on-off.result
>> @@ -47,6 +47,91 @@ box.error.injection.set("ERRINJ_WAL_DELAY", false)
>>    | - ok
>>    | ...
>>   +box.cfg{                                                                        \
>> +    election_mode = old_election_mode,                                          \
>> +}
>> + | ---
>> + | ...
>> +
>> +--
>> +-- Another crash could happen when election mode was configured to be
>> +-- 'candidate' with a known leader, but there was a not finished WAL write.
>> +-- The node tried to start waiting for the leader death, even though with an
>> +-- active WAL write it should wait for its end first.
>> +--
>> +box.schema.user.grant('guest', 'super')
> 
> 
> box.schema.user.grant('guest', 'replication') is enough.

I know. But I prefer using super, because it works always. I don't
want to think of the weakest possible rights which would fit. So
I usually add 'super' and forget about it.

>> + | ---
>> + | ...
>> +test_run:cmd('create server replica with rpl_master=default,\
>> +              script="replication/replica.lua"')
>> + | ---
>> + | - true
>> + | ...
>> +test_run:cmd('start server replica with wait=True, wait_load=True')
>> + | ---
>> + | - true
>> + | ...
>> +
>> +test_run:switch('replica')
>> + | ---
>> + | - true
>> + | ...
>> +box.cfg{election_mode = 'voter'}
>> + | ---
>> + | ...
>> +box.error.injection.set("ERRINJ_WAL_DELAY_COUNTDOWN", 0)
>> + | ---
>> + | - ok
>> + | ...
>> +
>> +test_run:switch('default')
>> + | ---
>> + | - true
>> + | ...
>> +box.cfg{election_mode = 'candidate'}
>> + | ---
>> + | ...
>> +test_run:wait_cond(function()                                                   \
>> +    return box.info.election.leader ~= 0                                        \
>> +end)
> 
> 
> Wouldn't it be simpler to wait for `box.info.election.state == 'leader'`?

I don't mind.

====================
diff --git a/test/replication/gh-5506-election-on-off.result b/test/replication/gh-5506-election-on-off.result
index 4fbc31986..b8abd7ecd 100644
--- a/test/replication/gh-5506-election-on-off.result
+++ b/test/replication/gh-5506-election-on-off.result
@@ -92,7 +92,7 @@ box.cfg{election_mode = 'candidate'}
  | ---
  | ...
 test_run:wait_cond(function()                                                   \
-    return box.info.election.leader ~= 0                                        \
+    return box.info.election.state == 'leader'                                  \
 end)
  | ---
  | - true
diff --git a/test/replication/gh-5506-election-on-off.test.lua b/test/replication/gh-5506-election-on-off.test.lua
index bb89477d1..476b00ec0 100644
--- a/test/replication/gh-5506-election-on-off.test.lua
+++ b/test/replication/gh-5506-election-on-off.test.lua
@@ -47,7 +47,7 @@ box.error.injection.set("ERRINJ_WAL_DELAY_COUNTDOWN", 0)
 test_run:switch('default')
 box.cfg{election_mode = 'candidate'}
 test_run:wait_cond(function()                                                   \
-    return box.info.election.leader ~= 0                                        \
+    return box.info.election.state == 'leader'                                  \
 end)
 
 test_run:switch('replica')

  reply	other threads:[~2020-11-09 22:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-07 16:45 [Tarantool-patches] [PATCH 0/2] Raft crash on re-enablence Vladislav Shpilevoy
2020-11-07 16:45 ` [Tarantool-patches] [PATCH 1/2] raft: fix crash on sm restart during WAL write Vladislav Shpilevoy
2020-11-09 10:16   ` Serge Petrenko
2020-11-07 16:45 ` [Tarantool-patches] [PATCH 2/2] raft: fix crash on candidate cfg " Vladislav Shpilevoy
2020-11-09 10:19   ` Serge Petrenko
2020-11-09 22:42     ` Vladislav Shpilevoy [this message]
2020-11-10  7:48       ` Serge Petrenko
2020-11-10 21:09 ` [Tarantool-patches] [PATCH 0/2] Raft crash on re-enablence Alexander V. Tikhonov
2020-11-10 22:05 ` Vladislav Shpilevoy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=043d73e1-9a87-12e6-c09f-f977beffc6f8@tarantool.org \
    --to=v.shpilevoy@tarantool.org \
    --cc=avtikhon@tarantool.org \
    --cc=sergepetrenko@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH 2/2] raft: fix crash on candidate cfg during WAL write' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox