Describe the bug

The new HGETEX command doesn't itself seem to flag the hash as cached by the client if you use it in isolation.

Here, we read f1 from hash with HGETEX but never receive an invalidation when the field expires.

$ redis-cli -p 9999 -3
127.0.0.1:9999> client tracking on
OK
127.0.0.1:9999> hmset hash f1 v1
OK
127.0.0.1:9999> hgetex hash ex 1 fields 1 f1
1) "v1"
127.0.0.1:9999> time
1) "1740969499"
2) "517076"
127.0.0.1:9999> time
1) "1740969501"
2) "603214"
127.0.0.1:9999> hgetall hash
(empty hash)

Note, that if I insert an HGETALL hash before the HGETEX I do see the invalidation.

Expected behavior

Receiving an invalidation when the field expires.

Additional information

redis-cli -p 9999 info server
# Server
redis_version:255.255.255
redis_git_sha1:7939ba03
redis_git_dirty:0
redis_build_id:4aacd1a1131a1c9f
redis_mode:standalone
os:Linux 6.8.0-52-generic x86_64
arch_bits:64
monotonic_clock:POSIX clock_gettime
multiplexing_api:epoll
atomicvar_api:c11-builtin
gcc_version:14.1.0
process_id:868082
process_supervised:no
run_id:9d935000c379d521b3f1170f80e9502bea3e77a5
tcp_port:9999
server_time_usec:1740970010442572
uptime_in_seconds:349793
uptime_in_days:4
hz:10
configured_hz:10
lru_clock:12916762
executable:/home/mike/dev/redis-dev/redis/src/redis-server
config_file:
io_threads_active:0
listener0:name=tcp,bind=*,bind=-::*,port=9999

Comment From: sundb

@michael-grunder HGETEX is not a READONLY command, the client shouldn't cache it.

Comment From: michael-grunder

Aha, so this is intended behavior. That actually makes my life much simpler on the client-side.

Thanks for the quick reply!