fix(certificate): unable to refresh certificate entity with vault reference when initial with an invalid string #14049
+422
−140
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…erence when initial with an invalid string (#10984) When set the cert to an invalid string in the vault, and then correct the string, kong will not start to use the correct certificate even though `kong vault` command shows the correct certiticate being returned. This is because the initial invalid string has already been cached in the L2 cache by mlcache, and it will not be updated via the L3 cache callback afterward. When mlcache fails during the execution of the `l1_serializer`, it caches the result retrieved from the L3 cache callback the first time in the L2 cache permanently. This means that subsequent calls to `cache.get()` will never fetch data from the L3 cache but will directly retrieve it from the L2 cache. To avoid this situation, when the `l1_serializer` fails, we no longer allow mlcache to store the data retrieved from L3 into L2.
github-actions
bot
added
the
cherry-pick kong-ee
ms2008
removed
the
cherry-pick kong-ee
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Manual backport https://github.com/Kong/kong-ee/pull/10984 to CE
Original description
Summary
When set the cert to an invalid string in the vault, and then correct the string, kong will not start to use the correct certificate even though
kong vaultcommand shows the correct certiticate being returned.This is because the initial invalid string has already been cached in the L2 cache by mlcache, and it will not be updated via the L3 cache callback afterward.
When mlcache fails during the execution of the
l1_serializer, it caches the result retrieved from the L3 cache callback the first time in the L2 cache permanently. This means that subsequent calls tocache.get()will never fetch data from the L3 cache but will directly retrieve it from the L2 cache.To avoid this situation, when the
l1_serializerfails, we no longer allow mlcache to store the data retrieved from L3 into L2.I believe this is more of a defect in mlcache. When mlcache fails during the execution of thel1_serializer, it caches the result retrieved from the L3 cache callback the first time in the L2 cache permanently. This means that subsequent calls tocache.get()will never fetch data from the L3 cache but will directly retrieve it from the L2 cache.From the perspective of mlcache, this doesn't seem to be an issue. When the data is updated, the invalidation should be explicitly triggered by the "data owner" themselves. This design allows mlcache to maximize its cache hit rate. However, in the case of Kong, this doesn't seem practical, as some data is stored in external systems, which cannot conveniently invalidate mlcache's cache, resulting in our inability to retrieve the most up-to-date data in a timely manner.
Checklist
CHANGELOG/unreleased/kongor addingskip-changeloglabel on PR if unnecessary. README.mdIssue reference
Fix FTI-6392