Implement FT.INFO command

[jruaux]

This PR implements the FT.INFO command to retrieve index information from RediSearch.

The implementation returns a IndexInfo object.

Changes:

• Add IndexInfo class with index information including:
  • Basic index information (name, document counts, terms, records)
  • Index options and definition
  • Schema attributes
  • Size statistics (memory usage)
  • Indexing statistics (progress, failures, timing)
  • Garbage collection statistics
  • Cursor statistics
  • Dialect usage statistics
  • Error statistics
• Add IndexInfoParser supporting both RESP2 and RESP3 protocols
• Implement ftInfo across all API layers (sync, async, reactive, coroutines)
• Add unit tests for IndexInfo class (11 tests, all passing)
• Update integration tests

Testing:
All unit tests pass. Integration tests require a Redis instance with RediSearch module.

---

Note

Medium Risk
Adds a new RediSearch command and a fairly complex RESP2/RESP3 response parser with new public model types, which could affect client compatibility and parsing correctness across Redis versions.

Overview
Adds support for the RediSearch FT.INFO command across sync/async/reactive/coroutines APIs, wiring it through RediSearchCommandBuilder and introducing the FT_INFO CommandType.

Introduces a new IndexInfo model (with nested typed stats/field definitions and a forward-compatible additionalFields map) plus an IndexInfoParser that parses both RESP2 and RESP3 responses. Adds unit tests covering option/definition/field/stat parsing scenarios and edge cases.

^{Reviewed by Cursor Bugbot for commit 4e904ef. Bugbot is set up for automated code reviews on this repo. Configure here.}

[tishun]

@a-TODO-rov went over the review and did some polishing myself:

• added @since anntations for 7.5
• fixed a few minor bugs in the parser
• executed the apigenerator to include the interface everywhere (was missing 2 files)
• etc.

IMHO we are good to go

[jit-ci]

🛡️ Jit Security Scan Results

✅ No security findings were detected in this PR

---

^{Security scan by Jit}

[cursor]

TextField weight always 0.0, never null when absent

Medium Severity

createTextField uses parseDouble(attributeMap.get(FLAG_WEIGHT)) which returns primitive double (defaulting to 0.0 when the key is absent). This gets autoboxed to Double.valueOf(0.0), so TextField.getWeight() never returns null — contradicting its documented contract of "or null if not set." The getDouble helper method already exists and correctly returns null for missing keys, so it looks like it was meant to be used here instead of parseDouble.

Additional Locations (1)

• src/main/java/io/lettuce/core/search/IndexInfo.java#L1464-L1468

 

[cursor]

RESP3 flags key leaks into vector attributes

Low Severity

In createVectorField, the exclusion list when building vectorAttributes does not include ATTR_FLAGS ("flags"). In RESP3, the attribute map contains a flags key with a List value (e.g., ["SORTABLE", "NOINDEX"]). This list is incorrectly included in vectorAttributes alongside actual vector attributes like DIM and DISTANCE_METRIC, polluting the map that VectorField.getAttributes() returns to callers.

 

[jruaux]

@tishun Can we include this in the next release?

[a-TODO-rov]

Hey, @jruaux
Me and @tishun have spent some time on this PR on a multiple occasions and i personally don't think its ready to be merged. Here are some of the problems i noticed so far:

1. This command has very complex response and its very different between RESP2/RESP3. I am concerned that this highly detailed parsing you are proposing is a huge overhead and might have some hidden bugs in it.
   Good example i think are the FIELDS - especially how the flags are being parsed - codesnippet:

for (int i = 0; i < list.size(); i += 2) {
    if (i + 1 < list.size()) {
        String key = decodeStringAsString(list.get(i));
        Object val = list.get(i + 1);
        // Handle special case where SORTABLE has a flag as its value (e.g., SORTABLE NOSTEM)
        // In this case, we need to add both SORTABLE and the flag (NOSTEM) as separate keys
        if (FLAG_SORTABLE.equals(key)) {
            attributeMap.put(key, val);
            String valStr = decodeStringAsString(val);
            // Check if the value is a known flag
            if (isFieldFlag(valStr)) {
                attributeMap.put(valStr, valStr);
            }
        } else {
            attributeMap.put(key, val);
        }
    }
}

How will this function behave for this response:

 7) attributes
 8) 1)  1) identifier
        2) title
        3) attribute
        4) product_title
        5) type
        6) TEXT
        7) WEIGHT
        8) "2"
        9) SORTABLE
       10) NOSTEM
       11) WITHSUFFIXTRIE

Will WITHSUFFIXTRIE be true ? This response is from testFtInfoCommand() integration test BTW.

2. We have ongoing initiative to start promoting the Search API to production and start removing the Experimental tags. For this to happen however we needed to revisit the codecs being used in Search. It seems they are unnecessary, even worse they might introduce bugs in some scenarios. So this PR aims to remove them where not applicable. However i see your PR is still using them - we need to evaluate if they are correctly used, but from first glance, i would say no.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

There are 4 total unresolved issues (including 2 from previous reviews).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 30c52c9. Configure here.}

[cursor]

RESP2 field parsing misidentifies values matching flag names

Medium Severity

In parseResp2FieldAttributes, the heuristic that checks if the next element is a standalone flag to treat the current element as standalone can misparse valid key-value pairs. If a field's attribute value happens to match a standalone flag name (e.g., a field aliased as "SORTABLE"), the parser incorrectly treats both the key and value as standalone flags instead of a key-value pair, losing the actual value.

 

^{Reviewed by Cursor Bugbot for commit 30c52c9. Configure here.}

[cursor]

Unused isFieldFlag method is dead code

Low Severity

The isFieldFlag method is defined but never called anywhere in the codebase. It appears to be leftover code superseded by the isStandaloneFlag and isFlagWithValue methods which handle the same classification. Its flag list also differs from isStandaloneFlag (missing SORTABLE and CASESENSITIVE, includes PHONETIC), adding confusion about the intended semantics.

 

^{Reviewed by Cursor Bugbot for commit 30c52c9. Configure here.}