I think this is not required. the problem is that some commands will create a new value (with NO key) and use setKey to change the value of an existing key. In this case the old can be replaced with the provided value and be left without a key however it is still a hashObject with optional volatile items.

I suggest to:

1. lets add assert checking that the object has a key in dbUntrackKeyWithVolatileItems and dbTrackKeyWithVolatileItems to be able to get a more explicit error in these cases
2. Maybe it was a mistake to implement dbUntrack/TrackKeyWithVolatileItems to assume the objects are always generic keys... we could change these functions to accept sds for the key
3. In this specific case (in order to avoid larger refactor) I think you can just add a condition in the next check, like:

/* If overwriting a hash object, un-track it from the volatile items tracking if it contains volatile items.*/
    if (old->type == OBJ_HASH && hashTypeHasVolatileFields(old)) {
        dbUntrackKeyWithVolatileItems(db, old->hasembkey ? old : new);
    }

Originally posted by @ranshid in #3007 (comment)