CrossPlatformLockError: Not able to acquire lock. Exceeded amount of retries set in options

[maorleger]

Core Library

MSAL Node (@azure/msal-node)

Wrapper Library

MSAL Node Extensions (@azure/msal-node-extensions)

Public or Confidential Client?

Public

Documentation Location

https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/extensions/docs/faq.md

Description

Related to Azure/azure-sdk-for-js#29920

@pcdeadeasy has reached out to us with the above error. It seems like, from looking at the code, that this can happen if the .lockfile file is not properly cleaned up.

Is there documentation about how a user can get themselves into a good state? If not, we think it should be documented or ideally self-healed (maybe by checking if the pid who owns the file is still running?)

Otherwise I can see a scenario where terminating processes at the wrong time may leave the system in a bad state.

Could we either document how to correct this issue as a user or self-heal within the code? We (@azure/identity-cache-persistence) can include that in our error message or troubleshooting guide.

@pcdeadeasy feel free to add any asks you have of the MSAL team.

Thanks in advance!

[pcdeadeasy]

Thanks for filing the issue @maorleger. I can consistently repro this on my machine. Restarting my laptop did not help either. I had to change my code so that token persistence happens with a named file and I was able to work around this.

[sameerag]

cc @bgavrilMS and @Robbie-Microsoft to check this

[bgavrilMS]

Hi @sameerag - this is a public client issue, as that caching mechanism was never designed for confidential clients (web apps don't use files etc.). @Robbie-Microsoft and I look after confidential client scenarios.

Afaik, the way to self heal is to close the app and delete the lock file manually. Possibly delete the cache file too.

The lock file should be always be deleted, even if the app crashes. There is special flag "DeleteOnClose" that should be used on file creation - see here - and also notice the special Windows flag used.

Also, there seems to be a workaround. Wondering if this is somehow related to Azure SDKs' default config for this cache.

[bgavrilMS]

Thanks for filing the issue @maorleger. I can consistently repro this on my machine. Restarting my laptop did not help either. I had to change my code so that token persistence happens with a named file and I was able to work around this.

This is interesting. @maorleger - where does Azure SDK default to create the file persistence if he app developer doesn't specify?

[maorleger]

Thanks for filing the issue @maorleger. I can consistently repro this on my machine. Restarting my laptop did not help either. I had to change my code so that token persistence happens with a named file and I was able to work around this.

This is interesting. @maorleger - where does Azure SDK default to create the file persistence if he app developer doesn't specify?

👋 By default we will use .IdentityService under the platform specific local folder as the directory. The file name will be msal.cache.<suffix> (where the suffix may be cae or nocae)

For example, on my wsl instance, it defaults to $HOME/.IdentityService/msal.cache.<suffix>

Hope that helps!

[dominic-simplan]

We are having the same issue in our Electron application which is using @azure/msal-node and the PersistenceCachePlugin from @azure/msal-node-extensions.
The issue has occured at least three times in the last three month on customer (Windows) systems. We don't know which constellation causes the issue though.