Allen Samuels

I like the concepts and directionality here. I think it would be profitable to split this into two subsections. One section would be to get more specific on the events...

I think it's important to provide an architecture that's lightweight enough that it could be enabled nearly everywhere -- maybe even by default. That means that the data collection needs...

I'm skeptical of the "one size fits all" interface style here. For example, using the end of call as your insertion point will miss all client commands that block. But...

Yes, multiple sources of data feeding the analysis engine. I believe a time-series processing module is in Valkey's future (likely with fidelity to the Redis time series module) and that...

Yes, let's focus initially on data collection. w.r.t. LUA scripts, my issue isn't about the speed of LUA vs C, but rather about the duplication of work in general. In...

I think this is a good start, the kinds of things that I'd like to see addressed in the next level of refinement is to: 1. Let's specific about the...

I'm skeptical that having a separate LUA instance for each tap attachment is the best approach. I can imagine situations where the desired metrics are synthesized by correlating events from...

I started an issue for dealing with ACL issues for search module. https://github.com/valkey-io/valkey/issues/2764 Seems like this work intersects with that, in particular, the current search code would not enforce these...

> > What's needed is key by key callback from the core when a key has been restored > > Just to clarify: this should be triggered both from rdb...

I'd say it should get trigger in all contexts. As long as there's enough server-events floating around for the Search module to understand what's going on. My reading of the...