Skip to main content
The Token Migrator runs in several phases. This page groups the logs written by the token-migrator container by phase, and 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. The logs are grouped into the following phases: initialization, determining in-scope clients, token migration iteration, and shutdown.

​
Initialization

​
Parsing arguments

These logs show the value of each argument and option in effect. If a provided value is missing or invalid, a WARN 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 acts as a control: token migration is performed 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 resolved client from the configured credentials is also used on behalf of the Token Migrator to create audit log events. All token change events performed by the Token Migrator are linked to this client. When an access token is obtained, logs like the following are written during startup:
The following examples show only the message part of each log line. If a required credential property is not configured, an error such as the following is logged:
  • token_request_url (set automatically via the Helm Chart)
  • service_token (set by the tokenmigrator.serviceToken credential in the authlete-credentials-secret.yml secrets):
If the client’s credentials cannot be validated, one of the following errors is logged with the reason. Check the client’s configuration in the destination environment and the credentials provided to the Token Migrator. The exact message depends on the error: Generic error, accompanied by a more detailed error message:
The service specified by tokenmigrator.serviceApiKey in the authlete-credentials-secret.yml secrets does not exist in the destination database:
The client with the configured alias does not exist (default alias is expected to be migration-service@system.authlete.com and cannot be changed in the Helm Chart):
The Process Token Request API returned an HTTP status other than 200:
The response from the Process Token Request API does not contain the 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:

​
Moving timestamp confirmation

When the Token Migrator restarts and continues from where it left off, it logs a non-zero moving timestamp. 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.

​
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

After initialization, 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 and can be very long. It is the complete record of the clients the Token Migrator handles.

​
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 decrypted 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:
Tokens of the clients in these logs are not migrated. If these logs are present, confirm and update the client secret of the affected clients. If this is logged for all clients, confirm that the client import or creation process keeps the client secret value when it creates the destination clients. See Client Token Migration Conditions for every condition a client must meet.

​
Token migration iteration

Next, the Token Migrator retrieves and copies the tokens of each in-scope client.

​
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:
When all tokens of a client for the queried time period are migrated, the following log is written, noting the time taken, the client, the number of tokens written, and the queried time period:

​
Shutdown logs

When the container is stopped, the Token Migrator logs, during shutdown, the last timestamp up to which it successfully processed token changes. You can use this value to recover the point to continue from if the state on the mounted volume is lost.