Repro steps:
- Create a profile named
my-profile in ~/.rai/config.
- Run a transaction with that profile. For example, create a
client object and do client.listDatabases.
- Change the client id and secret in
~/.rai/config to credentials associated with a different account.
- Run
client.listDatabases again.
Behavior
Expected behavior: get a list of databases from the new account.
Actual behavior: get a list of databases from the old account.
Diagnosis
It took me a very long time to figure this out, but I'm pretty sure it's because of readTokenCache.
Discussion
This hidden state makes debugging very difficult for people building applications, because you console log the credentials picked up by readConfig and see that they are correct, but then there's a mismatch with what you're getting back from the server. Since the server doesn't get information about the profile name, you know the caching isn't happening on that side.
Furthermore, I think this is likely to be a common scenario, because it comes up any time someone changes their mind about which credentials should be associated with a particular profile name. This might be because of a mistake, or because you want to change default to work around a lack of profile-specific behavior in the application that's using the SDK.
Proposed fix
The token cache could be keyed by profile name and client_id rather than just profile name. See Draft PR #59 for the idea.
Repro steps:
my-profilein~/.rai/config.clientobject and doclient.listDatabases.~/.rai/configto credentials associated with a different account.client.listDatabasesagain.Behavior
Expected behavior: get a list of databases from the new account.
Actual behavior: get a list of databases from the old account.
Diagnosis
It took me a very long time to figure this out, but I'm pretty sure it's because of
readTokenCache.Discussion
This hidden state makes debugging very difficult for people building applications, because you console log the credentials picked up by
readConfigand see that they are correct, but then there's a mismatch with what you're getting back from the server. Since the server doesn't get information about the profile name, you know the caching isn't happening on that side.Furthermore, I think this is likely to be a common scenario, because it comes up any time someone changes their mind about which credentials should be associated with a particular profile name. This might be because of a mistake, or because you want to change
defaultto work around a lack of profile-specific behavior in the application that's using the SDK.Proposed fix
The token cache could be keyed by profile name and
client_idrather than just profile name. See Draft PR #59 for the idea.