feat: send index definition for every thread

[BorysTheDev]

Send index definitions in every replica thread

[augmentcode]

🤖 Augment PR Summary

Summary: This PR changes snapshot/full-sync header generation so each replica flow (thread/shard) can receive search index definitions, rather than relying only on the summary flow.

Changes:

• Extended RdbSaver::GetGlobalData with an is_summary flag to control whether to emit full global state vs. per-shard index restore commands.
• DFS snapshot saving now passes the summary/per-shard intent explicitly when starting snapshots.
• Full sync header generation now includes index definitions for non-summary shard flows, while the summary flow still includes full global metadata.
• Refactored search-index collection into a helper that can emit either JSON (summary) or simple restore commands (per-shard).
• RDB loader now optionally ignores duplicate index-create errors when loading AUX search index definitions.

Technical Notes: Summary files retain JSON-based index definitions (including HNSW metadata) and synonym groups; per-shard files/flows emit simple FT.CREATE-compatible restore command payloads, with loader-side deduplication to tolerate multiple shards sending the same definition.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. 2 suggestions posted.

Comment augment review to trigger a new review at any time.

[Copilot]

Pull request overview

This PR modifies how search index definitions are sent during replication. Previously, search indices were only sent in the summary file from shard 0. Now, each replication thread (shard) sends its own index definitions.

Changes:

• Modified GetGlobalData to accept a bool is_summary parameter to differentiate between summary files (with full metadata) and per-shard files (with simple restore commands)
• Extracted search index collection into a new CollectSearchIndices helper function
• Updated all call sites to pass the appropriate is_summary value
• Added ignore_exists_error flag to handle duplicate index creation attempts on the replica

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/server/rdb_save.h	Updated GetGlobalData signature to accept is_summary parameter and added documentation
src/server/rdb_save.cc	Refactored search index collection into CollectSearchIndices function; modified GetGlobalData to handle summary vs per-shard modes differently
src/server/rdb_load.cc	Added ignore_exists_error parameter to handle duplicate index creation from multiple shard files
src/server/dflycmd.cc	Updated replication code to pass correct is_summary value based on save mode
src/server/detail/save_stages_controller.cc	Updated DFS and RDB save paths to pass is_summary parameter

[dranikpg]

The main reason why this is safe is because header serialization happens under a global lock

[dranikpg]

and once you settle on this format it will be difficult to change

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

[Copilot]

The check-then-create pattern for index existence is not thread-safe when multiple shard files are loaded concurrently. If two RdbLoader instances execute this code concurrently for the same index, both might see that the index doesn't exist at line 2992, and both will proceed to call LoadSearchCommandFromAux at line 3000. While FT.CREATE itself also checks for duplicates (search_family.cc:1235-1250) and prevents actual duplicate creation, this will result in unnecessary error logs from the second attempt. Consider using a mutex or other synchronization mechanism to make the check-and-create atomic, or accept that duplicate attempts may occur and suppress the expected error logs.

Suggested change

	// Check if index already exists (may have been created by another shard file)
	bool exists = shard_set->Await(
	0, [&] { return EngineShard::tlocal()->search_indices()->GetIndex(index_name) != nullptr; });
	if (exists) {
	VLOG(1) << "Index already exists, skipping: " << index_name;
	return;
	}
	// Delegate existence and duplicate handling to FT.CREATE itself.

[Copilot]

When is_summary=false, the code uses RunBriefInParallel and checks if (shard->shard_id() == 0) to collect indices from only shard 0. This causes all shards to execute the lambda, but only shard 0 does actual work. Consider using shard_set->Await(0, [&] { CollectSearchIndices(...); return OpStatus::OK; }) instead to execute only on shard 0, avoiding unnecessary fiber scheduling overhead on other shards.

Suggested change

	shard_set->RunBriefInParallel([&](EngineShard* shard) {
	if (shard->shard_id() == 0)
	CollectSearchIndices(shard, &search_indices, &search_synonyms, is_summary);
	shard_set->Await(0, [&](EngineShard* shard) {
	CollectSearchIndices(shard, &search_indices, &search_synonyms, is_summary);
	return OpStatus::OK;