@hwware can you describe in which scenario this would be useful?
i'm not sure this is useful for an application or even a database admin.

maybe it can be useful for the tests in some way (i.e. some wait_for_condition) after a deferred client performs registration, instead of assuming the server finished processing the registration (which can fail the tests on timing issues on some slow CI machines / valgrind).
@nitaicaro maybe this can be useful in #7998?

hi @oranagra , I think both administration and debugging purpose may use this.
sometimes when client side enables tracking, it may useful to show current tracking mode after long run (suppose client side does not save the current tracking mode on purpose). It can also helps for administor verify tracking for different clients is in desired mode, since these tracking modes will have totally different behaviour when and where the invalidation happens. thanks!

Related #7309.

I think as a debugging tool this is also missing the prefixes being tracked and client redirects. I'm not sure on their own this information is that useful.

thanks @madolson , yes we can show it here the bcast prefix. But I think the prefix related API like (add/delete/show) was missing, like i mentioned in #8003 (comment), do you think we should provide these APIs also?
Regarding the client redirects, AFAIK we can use the "client getredir" for current client redirection, do we also want to show it in client list reply too? thanks

Also one thing I am littlle bit worried about adding prefixes into the CLIENT LIST command is if client has long list of prefixes, this could affect the readability of the the reply, or shoud we build a separate API which returns an array type for that?

my 2 (possibly uninformed) cents:

1. I think we can indeed add tracking flags to CLIENT LIST (and add a CLIENT INFO only about the current client). the important flags are the mode of operation (to know if it's enabled, BGAST, redirect), not sure if the OPTIN/OPTOUT or other behavior flags are needed.
2. a CLIENT TRACKING INFO (or STATUS) command will be nice, should probably return a map of the various options, including a list of prefixes.
3. i'm not sure we want an option to remove specific patters or not. maybe we would expect a client to just wipe the old ones and re-register the ones it wants to keep?

Thanks @oranagra for your suggestions. I also think we can provide a API for returning current client tracking status, but two things we need to think about before jump into the implementation:

1. If we use CLIENT TRACKING INFO that would make CLIENT TRACKING subcommand more complex, since IMHO its a very complex pattern already. or we can choose a separate subcommand like CLIENT TRACKINGINFO like that?
2. I saw Salvatore already implementated showing some tracking info in a separate command, like the CLIENT GETREDIR, and showing some tracking flags in CLIENT LIST (or our future CLIENT INFO). if we provide a summerize subcommand for all the tracking information we might leave some redundancy here, another way is maybe we just provide a subcommand to show all the prefixes in bcast mode?
   Also regarding the third point (the add/delete prefixes), @madolson and I we discussed in [BUG] Duplicate invalidation message when turning tracking with BCAST option on with and without prefixes #8003 , maybe we can leave it for now until other users raised this request? How do you think?
   Thank you!

show the tracking flags in client list is a way, but it seems not easy to read, we already have too many single char client flags, and I think the client side caching is an independent system, I'd like a new subcommand to show the info as I wrote in PR #7309 , just my personal opinion.

Hi @soloestoy , sorry i forgot you already implemented the client tracking status command :).. I think it would be nice if we can have both, that means showing flags in client list command, and have a separate client tracking status subcommand as you impemented, how do you think?

@hwware looking at the syntax of CLIENT TRACKING i agree that it should not be added a sub-command (currently is a "set" command that sets many different options, we need a separate "get" command).
i think we should add something like CLIENT TRACKINGINFO.
i think such a command should return a RESP map (not a string like what's currently in #7309).
i don't like the GETREDIR, GETPREFIXES, approach.
@soloestoy if you agree, wanna modify #7309?

regarding this PR, i don't mind the overlapping, and the fact these one char flags are hard to read (it is meant for crash logs and maybe monitoring / debugging software).
as i stated earlier, what's important is to have here the tracking mode (enabled, BCAST, redirect, etc). the OPTIN / OPTOUT and other behavior flags are less important IMHO.
i mean, if we don't have to, i rather not add flags that we'll document and some day need to break.
so if you agree that they're not necessary, i rather drop them, but if you disagree and think they're necessary (i.e. may be important for a crash log or a debugging software), let's keep them.

Hi @oranagra , thank you for your comments, I agree with you if we only consider about the debugging purpose, the OPTIN/OPTOUT/NOLOOP mode is less useful, we can still show this information in future CLIENT TRACKINGINFO command . However for bcast mode, since it is completely using two different approaches for tracking. this we should add it in flags here both for debugging and monitoring purposes.
I can update this PR for only containing the BCAST flag and showing redirection clients, how do you think?

@hwware i'm in favor (only added what seems right rather than all that's possible).

LOL, so much talk over 4 short lines of code..
let's make use of it (this long discussion) and implement the conclusions.
@soloestoy do you agree? do you wanna modify your PR ask someone else to have a go at it?

From the crash log point of view, it's ok we can keep the one char flags, I will modify my PR change to CLIENT TRACKINGINFO

hi @oranagra , I added these changes based on the conversion, please review this, thanks!

@redis/core-team please approve new flag and new field for CLIENT LIST about tracking (BCAST flag, and redirect client ID)

@hwware can you please make a PR for redis-doc?

thanks @oranagra for the reminder, please see redis/redis-doc#1440