Skip to main content
The Token Migrator resumes automatically after it is stopped, whether intentionally or not. It saves its progress on the persistent volume that the Helm chart mounts. When it restarts with the same volume, it continues from the last saved point. It may reprocess some tokens, but it never skips a token.

​
Token ID mapping files (mapping-output)

The mapping-output directory holds one file per client that maps each source token ID to its destination token ID. The Token Migrator uses these files to find the destination token to update when a source token changes. Each file is named <service ID>:<client ID>.json. The Token Migrator generates these files as part of migration processing. If the mapping files are lost, the Token Migrator regenerates them, but some tokens may then be created as new tokens in the destination instead of updating the existing mapped tokens. The earlier copies (stale tokens) remain in the destination, so a token that was refreshed or revoked in the source may still be valid there. In this situation, we recommend completely restarting the whole token migration. This involves stopping the Token Migrator, removing the migrated services and clients from the destination (keep the service and client that the Token Migrator uses), and deleting all files on the Token Migrator’s persistent volume. Then migrate the services and clients again and start the Token Migrator.

​
Recovery point

​
How the moving timestamp is saved

During migration, the Token Migrator tracks a moving timestamp, which records the time up to which it has processed all token changes. After it has processed all token changes up to the current moving timestamp, it writes this value to timestamp.txt as a Unix epoch time in milliseconds (for example 1784401524667). This file is the recovery point in case the Token Migrator stops. On the next start, the Token Migrator continues from the time in timestamp.txt. Because the Token Migrator processes all token changes before it writes timestamp.txt, restarting from that point may reprocess tokens that were already created or updated, but it does not miss any token changes.

​
If timestamp.txt is lost

  1. Stop the Token Migrator (for example, set tokenmigrator.enabled to false and run helm upgrade).
  2. Find the last processed timestamp in the shutdown log: Shutting down sync migration task, latest timestamp [<value>]ms (see Shutdown logs).
  3. Create <mount path>/timestamp.txt containing only that value, in milliseconds.
  4. Start the Token Migrator again.
If the container was killed and no shutdown log was written, use an earlier timestamp that you are sure was already processed, such as the last Read in moving timestamp initial value log. Using an earlier timestamp only causes some tokens to be reprocessed.