During reshardCollection with zones, the coordinator writes the temporary collection's config.tags entries after the kInitializing -> kPreparingTodonate transaction commits here.

Specifically, writeParticipantShardsAndTempCollInfo does the following steps:

1. Remove stale temp chunks/tags and insert the initial chunks.
2. Commit the transaction that sets state: kPreparingToDonate, writes the participant lists, inserts the temp config.collections entry, and unsets zones and presetReshardedChunks.
3. Call setupZonesForTempNss to create config.tags entries for the temp namespace.

If the coordinator steps down or crashes between steps 2 and 3, the new primary loads the durable document as kPreparingToDonate. _calculateParticipantsAndChunksThenWriteToDisk returns early for that state, and setupZonesForTempNss being the only writer of temp tags the tags are never created. The zones input is already gone from the coordinator document, so recovery cannot recreate them.

At commit, the source namespace's tags are deleted and the temp tags are renamed to the source namespace. With no temp tags, the rename is a no-op and the resharded collection is left with no zones.

The impact is that even though the resharded data is correctly placed at commit respecting requested zone boundaries, the collection silently becomes unzoned afterwards (with new writes and balancer activity). With forceRedistribution, the effective zones may come from the source collection's existing config.tags entries (when the request omits zones). The commit deletes those source tags and expects the temp tags to replace them, so losing the temp tags drops the collection's pre-existing zones too.