Inconsistent `OBJECT`: Subcommands are not executing as expected

[sashpawar11]

Steps to reproduce

1. SETa key with a value
2. Execute a GET command on the key
3. Execute the OBJECT command with all the supported sub-commands ( ENCODING, REFCOUNT, FREQ, IDLETIME )

Expected output

The expected output when the above set of commands (maybe when run on Redis)

1. OBJECT ENCODING <key>

Returns the internal encoding for the  object stored at <key> : eg - raw, embstr, etc.

2. OBJECT FREQ <key>

If LRU policy exists , redis returns the access frequency of a key, if the LFU (Least Frequently Used) eviction policy is enabled.
If LRU policy does not exist , redis returns the following message:

(error) ERR An LFU maxmemory policy is not selected, access frequency not tracked. Please note that when switching between policies at runtime LRU and LFU data will take some time to adjust.

3. OBJECT REFCOUNT <key>

Returns the number of references of the value associated with the specified key.

Observed output

The observed output when the above set of commands when run on DiceDB

1. OBJECT ENCODING <key>

127.0.0.1:7379> OBJECT ENCODING mykey
(error) ERROR syntax error

2. OBJECT FREQ <key>

127.0.0.1:7379> OBJECT FREQ mykey
(error) ERROR syntax error

3. OBJECT REFCOUNT <key>

127.0.0.1:7379> OBJECT REFCOUNT mykey
(error) ERROR syntax error

Expectations for resolution

This issue will be considered resolved when the following things are done

1. changes in the dice code to meet the expected behavior
2. addition of relevant test case to ensure we catch the regression

You can find the tests under the integration_tests directory of the dice repository and the steps to run are in the README file. Refer to the following links to set up DiceDB and Redis 7.2.5 locally

• setup DiceDB locally
• setup Redis 7.2.5 locally
• setup DiceDB CLI

[RishabhC-137]

Can I take this ? @sashpawar11

[sashpawar11]

Hi @lucifercr07 @apoorvyadav1111 - Please review, and assign to me if the errors are legit. Encountered while auditing the doc on #834

[sashpawar11]

Root cause identified : We currently only support evalObjectIdleTime as a case in evalOBJECT.

Will add support for the other subcomands under this issue.

[sashpawar11]

Hi @lucifercr07 @apoorvyadav1111 - per redis docs and codebase, the following encoding types are defined and their logic built:

#define OBJ_ENCODING_RAW 0     /* Raw representation */
#define OBJ_ENCODING_INT 1     /* Encoded as integer */
#define OBJ_ENCODING_HT 2      /* Encoded as hash table */
#define OBJ_ENCODING_ZIPMAP 3  /* No longer used: old hash encoding. */
#define OBJ_ENCODING_LINKEDLIST 4 /* No longer used: old list encoding. */
#define OBJ_ENCODING_ZIPLIST 5 /* No longer used: old list/hash/zset encoding. */
#define OBJ_ENCODING_INTSET 6  /* Encoded as intset */
#define OBJ_ENCODING_SKIPLIST 7  /* Encoded as skiplist */
#define OBJ_ENCODING_EMBSTR 8  /* Embedded sds string encoding */
#define OBJ_ENCODING_QUICKLIST 9 /* Encoded as linked list of listpacks */
#define OBJ_ENCODING_STREAM 10 /* Encoded as a radix tree of listpacks */
#define OBJ_ENCODING_LISTPACK 11 /* Encoded as a listpack */
#define OBJ_ENCODING_LISTPACK_EX 12 /* Encoded as listpack, extended with metadata */

We are missing many of these in our codebase and their related logic > object.go, and also have some additional encoding types in their place.

Please advise if I should implement the command with whatever dice supports currently, ensuring that the OBJECT ENCODING <key> command will return currently supported encoding types from dice?

[sashpawar11]

Got clarification on the above on today's community call -> we will return what is supported in dice.

[sashpawar11]

This issue can be closed when all the below features have been completed: #964 #965 #966

@apoorvyadav1111 and me will be completing the above mentioned features. cc @lucifercr07 @JyotinderSingh

[arpitbbhayani]

Hello @sashpawar11,

There has been no activity on this issue for the past 5 days. It would be awesome if you keep posting updates to this issue so that we know you are actively working on it.

We are really eager to close this issue at the earliest, hence if we continue to see the inactivity, we will have to reassign the issue to someone else. We are doing this to ensure that the project maintains its momentum and others are not blocked on this work.

Just drop a comment with the current status of the work or share any issues you are facing. We can always chip in to help you out.

Thanks again.