Race condition when running multiple functions simultaneously produces invalid installation

[omermizr]

Token rotation must be enabled.
If the refresh token is about to expire (the SDK does this when there are less than 2 hours left on the expiry), and we run multiple functions simultaneously - in a Promise.all for instance - it seems the same refresh token is exchanged for 2 different fresh refresh tokens that have the same expires_at. At this point the SDK saves both tokens (via storeInstallation), but one is invalid and it is impossible to determine which one without trying it.
We've been having this issue since we started using the SDK.

I've tried to use the various callbacks to implement a user-land lock, but I couldn't quite get it to work because there's not enough control over what's being passed around.

Packages:

Select all that apply:

• @slack/web-api
• @slack/rtm-api
• @slack/webhooks
• @slack/oauth
• @slack/socket-mode
• @slack/types
• I don't know

Reproducible in:

The Slack SDK version

I've tried the same with older versions and latest

"slack/bolt": "^3.22.0",
"slack/oauth": "^2.6.3",
"slack/web-api": "^6.13.0",
"slack/webhook": "^7.0.3",

"slack/bolt": "^4.6.0",
"slack/oauth": "^3.0.4",
"slack/web-api": "^7.13.0",
"slack/webhook": "^7.0.6",

Node.js runtime version

v22.22.0

OS info

Docker - node:22.22.0-alpine3.22

Steps to reproduce:

0. Token rotation must be enabled
1. Refresh token about to expire
2. Multiple calls to a Slack function (chat.postMessage for instance) in a Promise.all
3. Internally, authorize() is called for all calls
4. fetchInstallation() is called for all calls
5. refreshExpiringToken() is called for all calls - 2 different refresh tokens are created
6. storeInstallation() is called for all calls

Expected result:

A single call to storeInstallation with a installation OR multiple calls with different expires_ats

Actual result:

Multiple calls to storeInstallation, with some installations immediately invalid

Requirements

For general questions/issues about Slack API platform or its server-side, could you submit questions at https://my.slack.com/help/requests/new instead. 🙇

Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

[zimeg]

Hey @omermizr! 👋 Thanks so much for sharing these impressive setups 💌

Would making a single call to the auth.test method before batching calls to the chat.postMessage method refresh the token before use?

[omermizr]

Thanks for the quick reply!
I'll need to look into that because I'm not sure if all calls go though the authorize() function, but assuming they do then yes, it should refresh the token.

However, if you're suggesting this should be done outside of the SDK then I'm not sure that makes sense - it would mean peppering consumer code with calls to auth.test before any batched operation. Will engineering remember to do that? Will the reason for doing this be clear? Will some engineer delete it assuming it's not needed in a few months? I think the right solution is somewhere in the installer initialization as opposed to living alongside business logic.
Also, if we have multiple instances doing similar work, this might still cause issues; multiple services/instances can decide they need to do a batched operation at the same time, and then we'll have simultaneous calls to auth.test. This is trickier to solve, and it's dependent on the installation store implementation (File-based, in-memory, or a real DB). I think a good way to solve this is to allow consumers to provide some locking mechanism (which would likely vary depending on the installation store implementation) - either via callbacks or by allowing to wrap the entire flow (fetch -> refresh/no-refresh-needed -> store) with a handler or something.
As a side note - this issue is worsened by the fact that the token expiration (expires_at) is in seconds - had it been in milliseconds, I doubt it would ever happen given JS's single-threaded nature.

These are just observations ans suggestions, but they make sense for our use case. I'm sure other people have this issue too, but might not even know it.

Thanks again :)

[omermizr]

Oh and I'm not sure if it was clear - we use these SDKs as part of bolt

[omermizr]

@zimeg So how do we proceed? Did you discuss this internally? Is there a plan to address this? Do you need to validate this first?
Can/should I make a PR for this? If so, I assume AI assistance is OK?

[omermizr]

@zimeg kind ping