Vladislav
Vladislav
> Do we have thread affinity on the master? We do on master, we don't have on slave
I will work and it will be more reliable than what we currently have, I just have this feeling that we overcomplicated because of not changing the message approach. Please...
Not sure if I have to start using the phrase "not sure" less 🤔
Its something we know, BRPOPLPUSH is the only command that has two hops and a write phase after unblocking and it doesn't respect transactions
Any order, once BRPOPLPUSH extracted a value, it will do a second hop and push it. While doing so, it doesn't check the continuation transacton, it just executes in PollExecution....
> I do not know if performance is important here, let's remove idempotent. Because...? And if you remove it for Ft.Info, why not for Ft.Search which have the same schematics?...
> Similarly with OOM checks - not clear to me why it is in Service::InvokeCmd and not inside DispatchCommand together with other checks - and inside multi to prevent the...
> VerifyCommandExecution should not be there. for multi/exec txs, move all verification checks to multi and similarly to how we fail the command if it has wrong arguments already during...
> Also, what's up with if (cmd_cntx->cid->name() == "REPLCONF" && absl::EqualsIgnoreCase(ArgS(tail_args, 0), "ACK")) { inside InvokeCmd? Why do we need it and why there? It was a bug I remember...
> what additional information do we have during exec? The one that is relevant when EXEC _actually_ executes: memory, acl, data store state, etc.