Handle missing config keys during checkpoint search

[abrookins]

When queried for checkpoints of a root graph, the config object the checkpointer receives may get checkpoint_id or checkpoint_ns keys with None or empty string values, or these keys may be missing. Our queries are not handling this situation well.

With an empty checkpoint_id, we end up querying for the literal None string:

1740785440.033103 [0 192.168.65.1:40503] "FT.SEARCH" "checkpoints" "((@thread_id:{book_flight_test} @checkpoint_ns:{respond\\:6b5253e5\\-407b\\-cf32\\-679b\\-cd3fa05fc42f}) @checkpoint_id:{None})" "RETURN" "6" "thread_id" "checkpoint_ns" "checkpoint_id" "parent_checkpoint_id" "$.checkpoint" "$.metadata" "SORTBY" "checkpoint_id" "DESC" "DIALECT" "2" "LIMIT" "0" "1"

This doesn't find anything, so the checkpointer fails to return conversation history, and memory "doesn't work."

On the other hand, if checkpoint_ns, is unset, we don't include it in the query. This conflicts with the Postgres and SQLlite checkpointer implementations, which search for a literal empty string in that case. The difference is that performing an exact match on only checkpoints whose checkpoint_ns is empty finds a different set of checkpoints than "find any matching checkpoint with or without a checkpoint_ns".

Our index doesn't support querying for empty strings on these fields (we would need the INDEXEMPTY option on fields, which RedisVL doesn't currently support and only recent versions of RediSearch support).

This commit doesn't entirely solve the problem, however. Now, we are searching for any checkpoint for the thread, not checkpoints with an empty checkpoint_id or checkpoint_ns. We need to store a sentinel value like "empty" and then query for it when the keys are not present in config.

[tylerhutcherson]

When queried for checkpoints of a root graph, the config object the checkpointer receives will not have a checkpoint_id or checkpoint_ns key. Currently, we reinterpret their absence as presence but with either an empty string or the string "None", neither of which will find anything when queried. One because we aren't saving the string "None," and the other because this index doesn't support querying for empty strings on these fields (would need the INDEXEMPTY option on fields, which RedisVL doesn't currently support and only recent versions of RediSearch support).

This commit doesn't entirely solve the problem, however. Now, we are searching for any checkpoint for the thread, not checkpoints for the thread for the root graph. We need to store a sentinel value like "empty" and then query for it when the keys are not present in config.

Good catch/fix. @abrookins let's create the ticket to address redisvl gaps in the field definitions for INDEXEMPTY. Assuming Redis throws some kind of error when applied in a non-supported version of Redis, I would be in favor of adding support in RedisVL and let the failure flow through. This is exactly the kind of scope for 0.5.0 we should address :)

[tylerhutcherson]

Looks great -- thanks!