Pass typed plugin option data to plugin in init #3582
Merged
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
just for convenience's sake
if the node fails to start (and we're expecting it to) return to us the node object anyway we also signal to collect all of its stderr logs by setting stderr on the tailableproc that backs the node
Changelog-Fixed: Plugins: if an option has a type int or bool, return the option as that type to the plugin's init
we loosely enforce that the specified type must be one of the listed options. you can still cause an error because we're not checking the default value you're passing in ... not sure if this is totally necessary, should we jsut let clightning enforce the input?
niftynei
force-pushed
the
nifty/plugin-types
branch
from
8e02ec2
to
6662c8f
Compare
also: convert the stored int value from 'int' to 's64' atoi fails silently, returning a zero. instead we use the more robust strtoll which will allow us fail with an error. we also make the parsing for bools stricter, only allowing plausibly boolean values to parse.
we also check that the node isn't running now, for extra pedancity
niftynei
force-pushed
the
nifty/plugin-types
branch
from
6662c8f
to
e9239d9
Compare
darosior
approved these changes
Mar 9, 2020
There was a problem hiding this comment.
ACK e9239d9
Tested against https://github.com/lightningd/plugins/, even though we don't test all options everywhere (some even register lightningd's ones..) it doesn't break any test, even without deprecated_apis. Great fix !
| @@ -250,6 +250,9 @@ def add_option(self, name, default, description, opt_type="string"): | |||
| "Name {} is already used by another option".format(name) | |||
| ) | |||
|
|
|||
| if opt_type not in ["string", "int", "bool"]: | |||
There was a problem hiding this comment.
[commit msg]
not sure if this is totally necessary, should we jsut let clightning
enforce the input?
Might be a bit redundant but an advantage is that one can see its mistake just by trying its plugin with python3 myplugin.py..
niftynei
commented
Mar 10, 2020
| if (streq(arg, "true") || streq(arg, "True") || streq(arg, "1")) { | ||
| *popt->value->as_bool = true; | ||
| } else if (streq(arg, "false") || streq(arg, "False") | ||
| || streq(arg, "0") || streq(arg, "")) { |
There was a problem hiding this comment.
on second thought, i think that an option flag without a body is a true, i.e. --daemon is generally parsed as 'yes daemon'. will submit second PR to fix this.
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.
We're only passing string values of plugin options to plugins, despite soliticting a type from the plugin during the manifest pass.
In this PR, I will now pass the values down to plugins as the type they've specified.
Additionally, makes the input option parsing stricter and adds a new testing feature where we can capture stderr logs to verify error messages in. If you want to.