-
Notifications
You must be signed in to change notification settings - Fork 374
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reducing the token synchronize weight for existing tokens #2660
base: master
Are you sure you want to change the base?
Reducing the token synchronize weight for existing tokens #2660
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2660 +/- ##
============================================
- Coverage 56.39% 55.75% -0.64%
- Complexity 8267 8415 +148
============================================
Files 632 632
Lines 46681 48509 +1828
Branches 8508 8968 +460
============================================
+ Hits 26324 27047 +723
- Misses 16592 17615 +1023
- Partials 3765 3847 +82
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Additionally, this segment should strictly avoid any write or update operations. | ||
It was introduced to minimize traffic at the token issuance lock for certain token requests. | ||
*/ | ||
if (!(JWT.equalsIgnoreCase(tokenType) && getRenewWithoutRevokingExistingStatus() && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apart from "Default" and "JWT", token type there can be custom token types too, won't there any issue with this logic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that only two types of token issuer classes implement OauthTokenIssuer
interface in this repo, how come custom token flow exists?
Proposed changes in this pull request
The synchronize block at the token issuance path seems to lock read only flow, where issuing existing token. For readonly flow, there is no requirement of a synchronize lock. This refactoring reduces the traffic at the synchronized block.
When should this PR be merged
After approval of the Authorization product team and the product owner.
Follow up actions
PR builder test success and QA approval.