Repository navigation
Time series labels change order on replicas, after a full sync and after a slot migration #612
Description
A time series' labels can come back in another order on a replica, after a full sync, and after a slot migration. TS.INFO (and so DEBUG DIGEST-VALUE) then differ between a master and its replica although the labels are the same.
Found in the 1.2.1 release re-test of 74071531.
- 1.2.1 master -> 1.2.1 replica, a workload of
TS.INCRBY ... LABELS grp inc n <i>andTS.ADD ... LABELS grp a: 26-28 of ~200 series differ byDEBUG DIGEST-VALUE; in every one the labels are the same pairs in another order ([[grp, inc], [n, 0]]on the master,[[n, 0], [grp, inc]]on the replica). Samples, retention, chunk size and policy are equal. - After a 1.2.0 replica full-syncs from a 1.2.1 master: 30 series, same thing.
CLUSTER MIGRATION IMPORTof slots holding series created withLABELS grp mig i <n>: 37-41 of 100 series come back on the destination with the pairs in the other order.
RedisTimeSeries returns labels in the order they were given. A client that reads TS.INFO or WITHLABELS positionally sees them change after a failover. The main harm is to tools that compare nodes by DEBUG DIGEST-VALUE: these show up as differences.
Expected: labels keep the order they were given, everywhere (or the digest does not depend on it).
Activity
murtazayusuf commentedon Nov 14, 2026
Tagged good first issue: the labels need to keep the order they were given in through replication, full sync and DUMP/RESTORE/slot migration (look at how a series' labels are stored and serialized in the time-series code and the snapshot writer). A good PR adds a test that creates series with several labels, full-syncs a replica (or DUMP/RESTOREs) and compares TS.INFO label order. Comment here before starting.