Re: [Tarantool-patches] [PATCH v14 0/6] qsync: implement packets filtering

[Vladislav Shpilevoy via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

Hi! Thanks for the fixes!

On 10.09.2021 17:29, Cyrill Gorcunov via Tarantool-patches wrote:
> Guys, take a look please, once time permit. The questionable moments:
> 
> - use filter disabling procedure for join/recovery: we make it so since
>   snapshot has promote record which fills initial limbo state

I still don't understand why do you need the disabling. Before the snapshot
is recovered, the limbo is empty and not owner by anybody. It is fully
valid and working, like if DEMOTE is called. Correct?

Snapshot's promote should make it belong to the owner persisted in promote.
Also correct?

The next rows just replay already applied data. Also correct?

It managed to apply first time and must manage to do so again. Agree?

In what of these statements I miss a mistake which makes you disable the
filtering?

> - need more tests to cover all possible scenarios
> 
> - I keep filter_confirm_rollback() as is but rereading Vlad's comment
>   >
>   > 9. What if rollback is for LSN > limbo's last LSN? It
>   > also means nothing to do. The same for confirm LSN < limbo's
>   > first LSN.
>   >
>   I presume I need to traverse limbo and test if incoming LSN is
>   present inside current queue.

It should be enough to know the LSN range in there AFAIU.


Additionally, I tried the test from the ticket again. It still
does not behave as expected. I remind, on the last review I also
tried:

	On top of the branch I tried the test I pasted in the
	ticket's description.

	I see the connection now breaks in one direction. But the
	new leader still follows the old leader somewhy.

And you said:

	I'll take more precise look, thanks!
	https://lists.tarantool.org/tarantool-patches/YRBUww6p1dUNL0mx@grain/

So what are the news on that? The new leader should not follow the old
one. If anything, even the vice-versa situation would be fine I
suppose - the old one following the new one. But the current way does
not look valid. The old leader could send all kinds of irrelevant
garbage and the new leader would happily swallow it.

The same happens in this test (on top of the last commit of this
patchset):
https://github.com/tarantool/tarantool/issues/5295#issuecomment-912106680
The new leader still replicates from the old broken one.