Tyk Unable to Deactivate a API Key

Branch/Environment/Version v5.0.0

Describe the bug
A clear and concise description of what the bug is.
We are running open-source Tyk Gateway to create/manage policies and keys. Also, we are using POST /tyk/keys/ API with "is_inactive": true if we need to block any Key.

However, we have noticed that if someone is continuously performing API Calls (in a while loop without any delays) and in-between Admin sends a request to deactivate a user (set "is_inactive": true) then the Key is not getting inactivated and user is still able to perform API Calls without any issues. The Admin API is not giving any error on the API Call

Further, if the requests received from user are not continuous then we are able to successfully deactivate the API Key.

Our Agenda is to deactivate an API Key on-the-fly but it’s not working for the above mentioned scenario.

Reproduction steps
Steps to reproduce the behaviour:

  1. Create a API (example: dev-api)
  2. Create a Key within that API
  3. Perform API Calls in infinite while loop
while [ true ]
do
    echo "started"
    curl --location 'http://localhost:9102/submit' --header 'Content-Type: application/json' --header 'Connection: close' --header 'Authorization: TOKEN'     
   echo "ended"
done

  1. Using Admin POST /tyk/keys/<KEY> endpoint set "is_inactive": true
  2. Using Admin GET /tyk/keys/<KEY> endpoint check is_inactive value in response - it will be still “false”

Actual behaviour
Currently, the API Key is not being deactivated once we set is_inactive=true

Expected behaviour
Ideally, the API Key should be deactivated once we set is_inactive=true

Hello @manjeet, and welcome to the community :partying_face:

Thanks for reporting this. I followed through the steps but I could not reproduce the issue.

I used a PUT since that is what is expected rather than a POST, so maybe that’s what the difference was

PUT /tyk/keys/{{key_id}} HTTP/1.1
Host: {{host}}:{{port}}
x-tyk-authorization: {{gateway_secret}}
Content-Type: application/json

Can you try that and let us know if that resolves it? If not then, try hot reloading the gateway to see if that fixes it.

If neither resolves the issue then please let is know. Sharing more information like the body of the request may help us get to the bottom of this