now i wonder if we really need to backport this fix to 7.0 and 6.2.

it doesn't have any implications on redis, but it does have on ACL LIST
so maybe it'll cause some noise (like what it did for the existing test), and we should avoid it?

so maybe it'll cause some noise (like what it did for the existing test), and we should avoid it?

yes, maybe. but i don't think people will rely on it, i think people rarely use ACL SETUSER reset? even if it use it, i think this noise is not a problem.

I think we can backport this fix to 7.0, and leave 6.2 as is, if we think the noise will be a problem

i discussed this with Yossi now, and he feels that it's better to keep this change out of 7.0 since there's a chance it'll break some app. specifically because this flag and it's syntax is probably not handled by users who interpret ACL LIST since (this is niche flag, and because of the bug, people didn't bother to add support for it when 6.2 came out).

the other alternative is to make it a tri-state flag (0,1,2), where 0 is is an implicit sanitize and 1 is an explicit one, so in essence officially supporting what we had when 6.2 release.
for that we need to revert your recent update and change reset to do what newly created user had.

the other alternative is to make it a tri-state flag (0,1,2), where 0 is is an implicit sanitize and 1 is an explicit one, so in essence officially supporting what we had when 6.2 release.
for that we need to revert your recent update and change reset to do what newly created user had.

so should we take this alternative? like i need to remove the change in ACLCreateUser, and go back to my fisrt commit (remove the ACLSetUser "sanitize-payload" in reset)? this looks like a safe way that we can do the backport

or we postpone it until 7.2 (with a better way to solve it)

thought about it again.. even with the tri-state, i can argue that there's no rush to fix it in 7.0.
and on the other hand, i'm afraid to introduce a new concept (a tri-state flag) into ACL and later realize that there's something we were missing.
so it's safer to just flow with the existing boolean flags (like on and off`).

so the bottom line is, we'll keep the current code, and just avoid backporting it to 7.0
sounds ok?

yeah. sounds good to me