Re: [Tarantool-patches] [RFC v29 3/3] test: add gh-6036-qsync-order test

[Serge Petrenko via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

01.02.2022 00:55, Cyrill Gorcunov пишет:
> To test that promotion requests are handled only when appropriate
> write to WAL completes, because we update memory data before the
> write finishes.
>
> Part-of #6036
>
> Signed-off-by: Cyrill Gorcunov<gorcunov@gmail.com>
> ---
>   .../gh_6036_qsync_order_test.lua              | 137 ++++++++++++++++++
>   test/replication-luatest/suite.ini            |   1 +
>   2 files changed, 138 insertions(+)
>   create mode 100644 test/replication-luatest/gh_6036_qsync_order_test.lua
>
> diff --git a/test/replication-luatest/gh_6036_qsync_order_test.lua b/test/replication-luatest/gh_6036_qsync_order_test.lua
> new file mode 100644
> index 000000000..4c0059764
> --- /dev/null
> +++ b/test/replication-luatest/gh_6036_qsync_order_test.lua
> @@ -0,0 +1,137 @@
> +local t = require('luatest')
> +local cluster = require('test.luatest_helpers.cluster')
> +local asserts = require('test.luatest_helpers.asserts')
> +local helpers = require('test.luatest_helpers')
> +local log = require('log')
> +
> +local g = t.group('gh-6036', {{engine = 'memtx'}, {engine = 'vinyl'}})


You don't need to test engines here.

You always create a memtx space anyway.

> +
> +g.before_each(function(cg)
> +    pcall(log.cfg, {level = 6})


You don't use log on the default instance. Why do you need that?

Does it help luatest output somehow?


> +
> +    local engine = cg.params.engine
> +
> +    cg.cluster = cluster:new({})
> +


Otherwise the test looks fine. Congratulations on writing your first 
luatest-test!


Now on the promote/demote test. It should be fairly easy to implement.

You only need 2 servers with election mode off and synchro quorum = 1, 
and a sync space.

1. promote server1

2. wait until the promotion is replicated

3. initiate wal delay on server2

4. issue box.ctl.promote() on server2 (it will block on box_issue_promote())

5. while server2 is blocked on writing a promote, do insert{1} on server1

6. wait for replication to server2 (wal is blocked, so rely on 
ERRINJ_WAL_WRITE_COUNT)

7. unblock wal on server2

8. make sure insert{1} wasn't applied on server2.


Speaking of the demote test. Demotion only works on the queue owner, so 
no one should be able

to write obsolete data during the DEMOTE wal write. I  can't think of a 
test here and I think we may

leave it untested.