[I] HSETEXPIRE with an overflowing TTL returns OK and deletes the whole hash [kvrocks]

["anubhavgupta121 (via GitHub)" <gi...@apache.org>]

anubhavgupta121 opened a new issue, #3698:
URL: https://github.com/apache/kvrocks/issues/3698

   ### Search before asking
   
   - [x] I had searched in the [issues](https://github.com/apache/kvrocks/issues) and found no similar issues.
   
   
   ### Version
   
   unstable, commit d8aeed4 (Linux x86_64)
   
   ### Minimal reproduce step
   
   HSET h f1 v1
   HSETEXPIRE h 18446744073709551 f2 v2
   HGETALL h
   EXISTS h
   
   
   ### What did you expect to see?
   
   An `invalid expire time` error, with `h` unchanged (`f1 -> v1`, no TTL).
   
   
   ### What did you see instead?
   
   `HSETEXPIRE` returns `OK`, `HGETALL` is empty and `EXISTS` returns 0. Both the new field and the existing `f1` are gone.
   
   
   ### Anything Else?
   
   `CommandHSetExpire` in `src/commands/cmd_hash.cc` parses the TTL as `uint64_t` with no upper bound, then passes `ttl_ * 1000 + util::GetTimeStampMS()` to `Hash::MSet`, which sets it as the key's metadata expire.
   
   With `ttl = 18446744073709551`, `ttl * 1000` is just under 2^64. Adding the current time wraps it to a moment in the past, so the whole hash expires immediately. `18446744073709551615` behaves the same way.
   
   This is the same class of bug as #3674 (`SET ... EX` overflow). PR #3680 does not cover HSETEXPIRE. `SET k v EX 9223372036854775807` from #3674 also reproduces on the same build.
   
   
   ### Are you willing to submit a PR?
   
   - [x] I'm willing to submit a PR!


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@kvrocks.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org