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.
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
wasm: clean up the code #36556
wasm: clean up the code #36556
Changes from all commits
e472ab7
6106740
2cc8acb
3a8fd67
91f2db4
8270067
8ad8cd0
99c7386
80f9eef
f89926e
0bbd11d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Some cases of the old logic that this refactoring consolidates used different log levels here depending on whether or not
plugin->fail_open_
was true. Can that be preserved?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.
Also (optionally) you might consider having the PluginConfig constructor take an additional string param for the role of the plugin (e.g. "stat sink" vs. "access logger" vs. "HTTP filter" etc.), so that can be retained in the log message here. While it isn't strictly necessary functionality-wise, I think it is useful information in the log message, since plugin failure could occur in a number of contexts.
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.
The fail_open self will be deprecated in favor of new FailurePolicy in the Envoy. And I think it acutally make no big sense to keep that 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.
I personally think the plugin name should be enough to distinguish different extension and their type. But I don't oppose it. I will add a TODO first until some acutally user ask it. (By the way, we created wasm bootstrap extension, wasm network extension, http extension, logger extension, etc, but we don't know how much of them is what the users actually want. At least from recently problems/bug, I think even the http wasm extension is not be accepted/used widely. We do too much things before get actual practising feedbacks and requirements.)
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.
SG--didn't know about that!
Fair enough--SGTM.
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.
Can we restructure this to avoid exceptions?
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.
Great suggestion.
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.
I finally add a TODO first. Because this is in the constructor and we need to use creation_status to handle the error. That means we need to change code of lots of different positions at where this PluginConfig is used.
We can put it to separated PR.
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.
why not release assert if this never should be called by the implementation?
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.
This check is finally removed at #36456. Finally, we use the same way to treat the singleton handle and thread local handle.
So, I think we can leave it there for now?