Vladislav

Yes, for all. We can't store them selectively without query overhead

Oh, okay. That answers all of my questions above. If Dragonfly doesn't intend to support IDLETIME, then adding memory overhead just for WATCH isn't worth it.

Should i128 really be clamped to f64 like i64 is? ```rust impl From for JsValue { #[inline] fn from(value: i64) -> Self { if let Ok(value) = i32::try_from(value) { Self::Integer(value)...

We can, with global and non-atomic modes (possibly) I guess this is not the right issue to discuss such changes, but we need to keep two internal infos about the...

With https://github.com/dragonflydb/dragonfly/pull/871, cacheops tests will finally pass. Even in non atomic mode 🤨 (I ran them multiple times). I think we can close this issue then and continue our discussion...

Now passing

Based on the fact that the cpu usage in the outside case is well below 100% and no obvious bottleneck are present in the profiles [bench-bad](https://github.com/dragonflydb/dragonfly/assets/20553775/2e5559a9-c6ba-4a9e-b83e-e1906b0f99f8) [bench-good](https://github.com/dragonflydb/dragonfly/assets/20553775/9664df27-653d-4010-a8dc-52fa6abb318b) I assume this...

There are two options to running a single hop: either keep the base tx multi or not. With single-shard EVAL we decided to reduce it to a regular transaction, which...

Still needs some polishment, I also need to check the replica side more in detail

> it's quite large change with lots of conditions. Do you think it is possible to split it into smaller ones? I can split the core logic and then it's...