Currently when we store frontiers/checkpoints/etc, we persist key spans, which specifically are key spans that have had their tenant prefix, as added by the codec that planned the job, included. This means that these job progress values are invalid if they is restored or replication streamed into a different tenant ID, which will "rekey" the every kv, replacing the tenant prefix with the new one, but leave the value as-is. Values, essentially, should be position-independent w.r.t. their tenant ID.
Epic: 8817
Currently when we store frontiers/checkpoints/etc, we persist key spans, which specifically are key spans that have had their tenant prefix, as added by the codec that planned the job, included. This means that these job progress values are invalid if they is restored or replication streamed into a different tenant ID, which will "rekey" the every kv, replacing the tenant prefix with the new one, but leave the value as-is. Values, essentially, should be position-independent w.r.t. their tenant ID.
Epic: 8817