Bug Report: PlannedReparentShard/EmergencyReparentShard silently return empty keyspace/shard on early reparent failure

[lmorduch]

Overview of the Issue

Both PlannedReparentShard and EmergencyReparentShard in grpcvtctldserver silently return empty keyspace and shard fields in their response when reparentShardLocked returns an error before the ev.ShardInfo = *shardInfo assignment.

Both handlers initialise the response with the request values, then overwrite unconditionally from ev.ShardInfo:

resp = &vtctldatapb.PlannedReparentShardResponse{
    Keyspace: req.Keyspace,
    Shard:    req.Shard,
}
if ev != nil {
    resp.Keyspace = ev.ShardInfo.Keyspace() // returns "" when ShardInfo is zero-valued
    resp.Shard    = ev.ShardInfo.ShardName()
    ...
}

ev is always non-nil, but ev.ShardInfo is zero-valued on any error path that exits reparentShardLocked before reaching ev.ShardInfo = *shardInfo. This overwrites the correct request values with empty strings, producing a response with keyspace: "" and shard: "".

For PRS the affected paths are: GetShard failure, GetKeyspaceDurability failure, GetDurabilityPolicy failure, and ExpectedPrimary mismatch (all before the ev.ShardInfo assignment). For ERS: GetShard failure (the only path before the assignment).

Reproduction Steps

For PlannedReparentShard: call with expected_primary set to a tablet alias that does not match the current primary. The ExpectedPrimary check in reparentShardLocked fires before ev.ShardInfo = *shardInfo, leaving ev.ShardInfo zero-valued. The response comes back with keyspace: "" and shard: "" instead of the request values.

Binary Version

Observed on vitess main.

Operating System and Environment details

N/A

Log Fragments

N/A

[lmorduch]

PR up: #20185