I’ve been using the Pivotal Tracker gem by Justin Smestad on a project to do various things but I ran into a problem using it with multiple API keys. The gem would create a single connection object and continue to mimic the user the first connection was made with, even when you’d updated the token to different user’s token. The Tracker API relies on you passing your API key for access to the projects and stories your account has access to, so I had the problem that the first user to use my app would determin access for everyone using the app. Not good!

After checking out the project the change was pretty simple but it highlighted an issue that I’ve seen in plenty of code where caching is done too broadly. In this case the cacheing (or memoization) was performed without taking into account the variable that was sent to establish the connection in the first place. The offending method looked like this :

Can’t see this Gist? View it on Github!

This was set on the class and as such @connection would never be created after the first call, whether the token was reset or not. I just changed it so that the connection is cached for each @token the system uses. For us it’s a small number or users, but in a larger context of course you’d need to implement some invalidation protocols to stop the following code from (slowly) swallowing the world :

Can’t see this Gist? View it on Github!

NoToken is just a class inheriting from StandardError that I chucked in there, the only thing that makes the gem now work properly come afterwards. I setup a hash and then store a new connection for each new incoming token, the connection is keyed by the token in the @connections hash. All pretty simple.

I’ve created a pull request that will hopefully be accepted soon, I think it fixes an unexpected problem with the gem.