FT.DROPINDEX DD Didn’t Delete All Documents in Redis Cloud – Redis Knowledge Base

In Redis Cloud databases with Search enabled, the command FT.DROPINDEX <index> DD removes both the index and its indexed documents. Some documents may remain if indexing was incomplete, failed due to schema/type mismatches, or if the command was issued in a distributed (Active-Active) environment.
This article explains command behavior, common causes of partial deletion, and the recommended troubleshooting and cleanup workflow in Redis Cloud.
Covered: How FT.DROPINDEX DD works, Common Causes, Troubleshooting, Cloud-specific Considerations, Workarounds, and Best Practices.

Prerequisites

Redis Cloud database with Search capability enabled
Database Admin or Owner role (for CLI or API access)
Familiarity with key prefixes and your index schema
Access to the Redis Cloud CLI or REST API

How FT.DROPINDEX DD Works

Without DD: Removes only the index structure; documents remain.
With DD: Removes the index and all documents that were successfully indexed.

Deletion is asynchronous for large indexes, so documents may remain visible briefly during cleanup.
Read more on FT.DROPINDEX

Common Reasons Documents Weren’t Deleted

Cause	Explanation
Incomplete indexing	If indexing was still in progress, only already-indexed documents were deleted.
Indexing failures	Schema or type mismatches (for example, strings in `NUMERIC` fields) prevent some documents from being indexed. These are not deleted.
Timeouts or large datasets	On busy or large databases, deletions may time out or leave some keys unprocessed.

Step-by-Step Troubleshooting

Check indexing status

Before dropping the index, verify it is fully populated:

FT.INFO <index>

Confirm:

indexing = 0
percent_indexed = 1 (or 100%)
hash_indexing_failures = 0

If failures exist, fix the affected data or schema before proceeding.

Validate remaining keys

After deletion, confirm whether any keys remain:

EXISTS <key>
SCAN 0 MATCH prefix:* COUNT 1000

If matches remain, those hashes were likely never indexed or were written after the index started building.

Clean up remaining keys

Use UNLINK for safe, non-blocking deletion:

redis-cli --scan --pattern "prefix:*" | xargs redis-cli UNLINK

Avoid DEL for large datasets—it can block the Redis main thread.

Special Considerations for Redis Cloud

Active-Active (CRDB): Run FT.DROPINDEX DD in all clusters for global deletion.
Replica propagation: Deletes may not replicate if transient failures occur.
Scaling: Large indexes and keyspaces may take longer to clean up.

Workarounds and Best Practices

Wait until indexing=0 before using DD.
Regularly check hash_indexing_failures in FT.INFO. Read more on FT.INFO
Use consistent PREFIX values in FT.CREATE for easier cleanup.
In CRDB setups, repeat deletion across peers or use prefix-based cleanup.
Keep Redis Cloud and Redis Search modules up-to-date to ensure propagation reliability.

Troubleshooting Checklist

Check	Command / Action	What to Do
Index fully indexed?	`FT.INFO <index>` → confirm `indexing: 0`	Wait for indexing to complete or troubleshoot ingestion delays before retrying deletion.
Indexing failures?	`FT.INFO <index>` → check `hash_indexing_failures > 0`	Fix schema or type mismatches, then rebuild or reindex affected documents.
Prefix correct?	`SCAN 0 MATCH <prefix>* COUNT 1000`	Ensure your `FT.CREATE ... PREFIX` matches actual key naming. Adjust if misaligned.
Module versions current?	Check module version in Cloud Console or run `MODULE LIST`	Align Redis Search module versions across clusters or update if outdated.
CRDB setup?	Run `FT.DROPINDEX <index> DD` in all peer clusters	Execute on all Active-Active clusters to ensure full key cleanup.
Leftover keys?	`SCAN 0 MATCH <prefix>* COUNT 1000` → remove with `UNLINK`	Manually clean up any orphaned keys until none remain.

Example

FT.CREATE numeric_idx PREFIX 1 cnt: SCHEMA val NUMERIC
HSET cnt:1 val 5
HSET cnt:2 val "word"
FT.INFO numeric_idx
FT.DROPINDEX numeric_idx DD
EXISTS cnt:1  # (integer) 0
EXISTS cnt:2  # (integer) 1

cnt:2 remains because it failed to index due to a schema mismatch.

Related to