API_TOKEN_SALT generation strategy

Hi community!
I faced the same issue as described in the post.

We deploy our application in AWS. In our pipeline API_TOKEN_SALT is generated automatically by strapi and stored in Secrets Manager, but we read this value as an env variable in admin.js.

Based on documentation, if API_TOKEN_SALT is updated, it makes API tokens invalid. Our pipeline has been already existing for a year, but we faced this issue of 401 unauthorized only twice in random moments. It looks like some deployments trigger an update of auto-generated API_TOKEN_SALT.

I know that it’s better to have API_TOKEN_SALT as a static value, but I’m just curious what could trigger strapi to regenerate API_TOKEN_SALT if this value isn’t static? I’ve seen in the discussion of the issue on github that in some cases some deployments could use ‘previously generated’ tokens even if they were created with non-static API_TOKEN_SALT.

If you could give some explanation what is the strategy for API_TOKEN_SALT regeneration, it would be nice.

Thank you.