token-migrator container into the following phases: initialization, determining in-scope clients, token migration iteration, and shutdown. It explains what each log tells you and what to check when a log reports a problem.
This page is based on logs from Token Migrator version 1.4. When searching the logs, search by message text rather than by class line number (for example instead of ArgsUtils:113 search for No batch size provided), because line numbers are more likely to change between versions.
Initialization
Parsing arguments
These logs show the value of each argument and option in effect. If a value is not provided or is invalid, aWARN line shows the default value used instead.
Client credentials client resolution (audit log client)
The Token Migrator uses client credentials to verify that it can access the destination Authlete 3.0 environment. This check controls whether token migration runs: the Token Migrator migrates tokens only while these credentials are valid. During initialization, the Token Migrator calls the Process Token Request API of the destination Authlete 3.0 server with the client credentials grant. If it obtains an access token, initialization continues; otherwise the Token Migrator stops. The Token Migrator also uses the client that the configured credentials resolve to when it creates audit log events. All token changes made by the Token Migrator are linked to this client in the audit log. When an access token is obtained, logs like the following are written during startup:-
token_request_url(set automatically via the Helm Chart): -
service_token(set by thetokenmigrator.serviceTokencredential in theauthlete-credentials-secret.ymlsecrets):
tokenmigrator.serviceApiKey in the authlete-credentials-secret.yml secrets does not exist in the destination database:
migration-service@system.authlete.com and cannot be changed in the Helm Chart):
accessToken property:
Dry run indication
When the Token Migrator runs in dry run mode (tokenmigrator.mode: dryrun in values.yaml), no tokens are written, and the following log is written during initialization to confirm that dry run is enabled:
Last-processed timestamp confirmation
When the Token Migrator restarts and continues from where it left off, it logs a non-zero last-processed timestamp (shown asmoving timestamp in the log). This value is the last recovery point that the Token Migrator saved, and it looks for token changes after this point. See Stopping and Resuming the Token Migrator for details.
timestamp.txt, the following log is written instead of Read in moving timestamp initial value, and the Token Migrator starts from the initial timestamp given in its arguments (0 when none is provided):
Determining in-scope clients
After initialization succeeds, the Token Migrator moves on to the migration phase, starting with resolving the clients that are in scope for migration. The Token Migrator logs each new client that it detects and adds to the scope. Tokens of in-scope clients are checked and migrated when they are created or updated. The Token Migrator also logs when clients are removed from the scope. Each client is identified as<service ID>:<client ID>, for example 170886802516:143761865171655.
Initial client and service state
The current service and client state is logged once at the start of the migration phase:Clients added to scope
When clients are added to the migration scope, the following log is written. It contains the identifier of every client whose tokens will be considered for migration:This message lists every in-scope client, so you can use it to check which clients are in scope. It can be very long when there are many in-scope clients.
Clients removed from scope
When clients are removed from the scope, a similar message is written:Client secret doesn’t match
A client is added to the scope only if its client secret is the same in the source and destination databases. If a client meets all other conditions but is excluded only because its client secret does not match, the following warning is logged:Token migration iteration
Next, the Token Migrator retrieves the tokens of each in-scope client and copies them to the destination database.Found tokens
For each client, the Token Migrator logs how many tokens it found and will migrate, and the time period that was queried:Migrating tokens
For each batch of tokens written, the following log shows how many of the written tokens were updated and how many were created:Shutdown logs
When the container is stopped, the Token Migrator logs, during shutdown, the last timestamp up to which it successfully processed token changes. Iftimestamp.txt on the persistent volume is lost, you can use this value to recover the point to continue from (see Stopping and Resuming the Token Migrator).