You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When multiple concurrent requests are made to the OAuth2 token generation endpoint in Kong 2.8.5, if a database transaction timeout occurs, sometimes the response contains an access token associated with a different authenticated_userid.
This issue suggests that there may be a concurrency problem where the plugin incorrectly returns a previously issued token instead of handling the failure properly.
Observed behavior in stress testing:
Some responses contain an access token belonging to another user instead of returning an error.
This occurs intermittently when database locks or timeouts happen while handling concurrent token requests.
Expected Behavior
When a database timeout or transaction failure occurs, Kong should not return a token for the wrong user. Instead, it should respond with an error.
Steps To Reproduce
Run a high-load test sending multiple simultaneous requests to the /oauth2/token endpoint and validate the returned access_token.
While the test is running, lock the oauth2_tokens table for a few seconds and then release it.
Repeat step 2 several times while observing the responses.
I also tested this in Kong 3.9.0.1, and the issue does not occur. In this version, Kong correctly returns an error when the database transaction fails, rather than returning an incorrect access token.
Let me know if more details are needed.
The text was updated successfully, but these errors were encountered:
Hi @alisonbudag , Thank you for your effort, but 2.8.5 is an old version and we only have LTS on 2.8 for Enterprise Edition. We encourage you to upgrade to newer version like 3.9, which doesn't have this issue as you tested.
Is there an existing issue for this?
Kong version (
$ kong version
)2.8.5
Current Behavior
When multiple concurrent requests are made to the OAuth2 token generation endpoint in Kong 2.8.5, if a database transaction timeout occurs, sometimes the response contains an access token associated with a different authenticated_userid.
This issue suggests that there may be a concurrency problem where the plugin incorrectly returns a previously issued token instead of handling the failure properly.
Observed behavior in stress testing:
Expected Behavior
When a database timeout or transaction failure occurs, Kong should not return a token for the wrong user. Instead, it should respond with an error.
Steps To Reproduce
Test setup
local-kong.yaml
local-kong-processor.js
Results:


Anything else?
I also tested this in Kong 3.9.0.1, and the issue does not occur. In this version, Kong correctly returns an error when the database transaction fails, rather than returning an incorrect access token.
Let me know if more details are needed.
The text was updated successfully, but these errors were encountered: