What

When a WalDelta automatic transfer fails, the driver falls back to the method passed in fallback_method (see transfer_shard_fallback_default in lib/collection/src/shards/transfer/driver.rs). Until now this was hard-coded in Collection::send_shard to:

let fallback_method = if self.is_prevent_unoptimized().await {
    ShardTransferMethod::Snapshot
} else {
    ShardTransferMethod::StreamRecords
};

This is inconsistent with the change in #8784 that made Snapshot the default transfer method for Qdrant 1.18.0+, and it also ignores any cluster-level default_shard_transfer_method override. As a result, when a WAL delta auto-recovery fails (e.g. recovery point has no clocks to resolve delta for), users on a clean 1.18 install see:

WARN collection::shards::transfer::driver: Failed to do shard diff transfer, falling back to default method StreamRecords: ...

…even though the cluster default is Snapshot.

Change

Use Collection::default_shard_transfer_method() for the fallback. This returns the configured default_shard_transfer_method or Snapshot for 1.18.0+.

prevent_unoptimized still pins to Snapshot to preserve deferred point state exactly (raw segment copy); StreamRecords would send deferred points but they would not be deferred on the target.

The existing safety in transfer_shard_fallback_default already refuses to fall back to the same method, so the case of WalDelta → fallback WalDelta is correctly handled (it aborts the fallback).

Test plan

• CI green
• Manual: trigger an automatic recovery on a 1.18 cluster with a WAL gap; confirm the fallback log now says Snapshot (or the configured default) instead of StreamRecords

All Submissions:

• Contributions should target the dev branch.

Made with Cursor