Bug Report: Shard ranges for 103 & 107 shards end in -ff

[bluecrabs007]

Overview of the Issue

There is a bug in the way the shard ranges are generated for 103 & 107 shards. For example.

vtctldclient --server=$host:15999 GenerateShardRanges 102 | tail -n 2
  "fd-"
]

vtctldclient --server=$host:15999 GenerateShardRanges 2 | tail -n 2
  "80-"
]

You can see that the ending ranges for 102 & 2 are what we typically expect.

But when you use 103 or 107, you get the ending range ending in -ff.

vtctldclient --server=$host:15999 GenerateShardRanges 103 | tail -n 2
  "fd-ff"
]

vtctldclient --server=$host:15999 GenerateShardRanges 107 | tail -n 2
  "fd-ff"
]

I have not deployed a keyspace with 103 or 107 shards, so not sure how the keyspace would work, but the output from the range generation logic seems to give unexpected results.

Reproduction Steps

Using the latest main, create a test cluster.
$ minikube start --kubernetes-version=v1.27.11 --cpus=4 --memory=11000 --disk-size=32g
$ kubectl apply -f examples/operator/operator.yaml
$ kubectl apply -f examples/operator/101_initial_cluster.yaml

And hit the vtctld service with the vtctldclient command shared above.

Binary Version

$ /vt/bin/vtgate --version
vtgate version Version: 20.0.0-SNAPSHOT (Git revision bec711bb837582ae32d81fa997ea30e08e1c5598 branch 'main') built on Fri May 31 19:18:34 UTC 2024 by vitess@buildkitsandbox using go1.22.3 linux/amd64

Operating System and Environment details

NA

Log Fragments

NA

[deepthi]

This seems important to fix before v20 because vtop is affected. I'll check if I can repro with small numbers like 3 and 5.

[deepthi]

There's something special about 103 and 107 :) Works fine with 3,5,7,9,55,101,105,109,111. Given that, I'd say that this isn't critical to fix, though certainly nice to fix.

% for i in 3 5 7 9 101 105 109 111
for> do
for> vtctldclient GenerateShardRanges $i | tail -n 2 | head -n 1
for> done
  "aa-"
  "cc-"
  "db-"
  "e3-"
  "fd-"
  "fd-"
  "fd-"
  "fd-"

[bluecrabs007]

There's something special about 103 and 107 :) Works fine with 3,5,7,9,55,101,105,109,111. Given that, I'd say that this isn't critical to fix, though certainly nice to fix.

% for i in 3 5 7 9 101 105 109 111
for> do
for> vtctldclient GenerateShardRanges $i | tail -n 2 | head -n 1
for> done
  "aa-"
  "cc-"
  "db-"
  "e3-"
  "fd-"
  "fd-"
  "fd-"
  "fd-"

Yes, its just 103 & 107 that are effected. I ran tests upto 128 shards.