Token update by hash generates new hash entry in redis #3109
Labels
Comments
17 tasks
buger
pushed a commit
that referenced
this issue
Jul 25, 2020
<!-- Provide a general summary of your changes in the Title above --> ## Description On update keys, we should not call twice `doAddOrUpdate` as this create duplicates for the same key in redis, instead, we should check if we are dealing with a custom key or not, and therefore perform the proper action. ## Related Issue #3109 ## Motivation and Context Give solution to #3109 ## How This Has Been Tested - Run GW and Dashboard with `"hash_keys": true` - Create a custom key via gw api - Update custom key...and check that the value was updated and an additional registry was not created in redis - Create key via dashboard - Update key via dashboard, check that the value was updated but an additional registry in redis was not created for the same key - Do the same but now with `"hash_keys": false` ## Screenshots (if appropriate) ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [x] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality) ## Checklist <!-- Go over all the following points, and put an `x` in all the boxes that apply --> <!-- If you're unsure about any of these, don't hesitate to ask; we're here to help! --> - [x] Make sure you are requesting to **pull a topic/feature/bugfix branch** (right side). If pulling from your own fork, don't request your `master`! - [x] Make sure you are making a pull request against the **`master` branch** (left side). Also, you should start *your branch* off *our latest `master`*. - [ ] My change requires a change to the documentation. - [ ] If you've changed APIs, describe what needs to be updated in the documentation. - [ ] If new config option added, ensure that it can be set via ENV variable - [ ] I have updated the documentation accordingly. - [ ] Modules and vendor dependencies have been updated; run `go mod tidy && go mod vendor` - [ ] When updating library version must provide reason/explanation for this update. - [x] I have added tests to cover my changes. - [x] All new and existing tests passed. - [x] Check your code additions will not fail linting checks: - [x] `go fmt -s` - [x] `go vet`
tykbot bot
pushed a commit
that referenced
this issue
Jul 25, 2020
<!-- Provide a general summary of your changes in the Title above --> ## Description On update keys, we should not call twice `doAddOrUpdate` as this create duplicates for the same key in redis, instead, we should check if we are dealing with a custom key or not, and therefore perform the proper action. ## Related Issue #3109 ## Motivation and Context Give solution to #3109 ## How This Has Been Tested - Run GW and Dashboard with `"hash_keys": true` - Create a custom key via gw api - Update custom key...and check that the value was updated and an additional registry was not created in redis - Create key via dashboard - Update key via dashboard, check that the value was updated but an additional registry in redis was not created for the same key - Do the same but now with `"hash_keys": false` ## Screenshots (if appropriate) ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [x] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality) ## Checklist <!-- Go over all the following points, and put an `x` in all the boxes that apply --> <!-- If you're unsure about any of these, don't hesitate to ask; we're here to help! --> - [x] Make sure you are requesting to **pull a topic/feature/bugfix branch** (right side). If pulling from your own fork, don't request your `master`! - [x] Make sure you are making a pull request against the **`master` branch** (left side). Also, you should start *your branch* off *our latest `master`*. - [ ] My change requires a change to the documentation. - [ ] If you've changed APIs, describe what needs to be updated in the documentation. - [ ] If new config option added, ensure that it can be set via ENV variable - [ ] I have updated the documentation accordingly. - [ ] Modules and vendor dependencies have been updated; run `go mod tidy && go mod vendor` - [ ] When updating library version must provide reason/explanation for this update. - [x] I have added tests to cover my changes. - [x] All new and existing tests passed. - [x] Check your code additions will not fail linting checks: - [x] `go fmt -s` - [x] `go vet` (cherry picked from commit 110cdf7)
tykbot bot
pushed a commit
that referenced
this issue
Jul 25, 2020
<!-- Provide a general summary of your changes in the Title above --> ## Description On update keys, we should not call twice `doAddOrUpdate` as this create duplicates for the same key in redis, instead, we should check if we are dealing with a custom key or not, and therefore perform the proper action. ## Related Issue #3109 ## Motivation and Context Give solution to #3109 ## How This Has Been Tested - Run GW and Dashboard with `"hash_keys": true` - Create a custom key via gw api - Update custom key...and check that the value was updated and an additional registry was not created in redis - Create key via dashboard - Update key via dashboard, check that the value was updated but an additional registry in redis was not created for the same key - Do the same but now with `"hash_keys": false` ## Screenshots (if appropriate) ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [x] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality) ## Checklist <!-- Go over all the following points, and put an `x` in all the boxes that apply --> <!-- If you're unsure about any of these, don't hesitate to ask; we're here to help! --> - [x] Make sure you are requesting to **pull a topic/feature/bugfix branch** (right side). If pulling from your own fork, don't request your `master`! - [x] Make sure you are making a pull request against the **`master` branch** (left side). Also, you should start *your branch* off *our latest `master`*. - [ ] My change requires a change to the documentation. - [ ] If you've changed APIs, describe what needs to be updated in the documentation. - [ ] If new config option added, ensure that it can be set via ENV variable - [ ] I have updated the documentation accordingly. - [ ] Modules and vendor dependencies have been updated; run `go mod tidy && go mod vendor` - [ ] When updating library version must provide reason/explanation for this update. - [x] I have added tests to cover my changes. - [x] All new and existing tests passed. - [x] Check your code additions will not fail linting checks: - [x] `go fmt -s` - [x] `go vet` (cherry picked from commit 110cdf7)
tykbot bot
pushed a commit
that referenced
this issue
Jul 25, 2020
<!-- Provide a general summary of your changes in the Title above --> ## Description On update keys, we should not call twice `doAddOrUpdate` as this create duplicates for the same key in redis, instead, we should check if we are dealing with a custom key or not, and therefore perform the proper action. ## Related Issue #3109 ## Motivation and Context Give solution to #3109 ## How This Has Been Tested - Run GW and Dashboard with `"hash_keys": true` - Create a custom key via gw api - Update custom key...and check that the value was updated and an additional registry was not created in redis - Create key via dashboard - Update key via dashboard, check that the value was updated but an additional registry in redis was not created for the same key - Do the same but now with `"hash_keys": false` ## Screenshots (if appropriate) ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [x] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality) ## Checklist <!-- Go over all the following points, and put an `x` in all the boxes that apply --> <!-- If you're unsure about any of these, don't hesitate to ask; we're here to help! --> - [x] Make sure you are requesting to **pull a topic/feature/bugfix branch** (right side). If pulling from your own fork, don't request your `master`! - [x] Make sure you are making a pull request against the **`master` branch** (left side). Also, you should start *your branch* off *our latest `master`*. - [ ] My change requires a change to the documentation. - [ ] If you've changed APIs, describe what needs to be updated in the documentation. - [ ] If new config option added, ensure that it can be set via ENV variable - [ ] I have updated the documentation accordingly. - [ ] Modules and vendor dependencies have been updated; run `go mod tidy && go mod vendor` - [ ] When updating library version must provide reason/explanation for this update. - [x] I have added tests to cover my changes. - [x] All new and existing tests passed. - [x] Check your code additions will not fail linting checks: - [x] `go fmt -s` - [x] `go vet` (cherry picked from commit 110cdf7)
|
Verified |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Branch/Environment/Version
Describe the bug
When user updates token by hash, gateway will create new hash entry in redis database.
Reproduction steps
Actual behavior
Before token update in redis we will have hash like this
api-3f2736714c0076a2, when we update token in redis we will have two entries:Expected behavior
Update token by hash should not create new token entry in redis.
Screenshots/Video
If applicable, add screenshots or video to help explain your problem.
Logs (debug mode or log file):
Log from console or from log file.
Configuration (tyk config file):
Attach tyk configuration file
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: