Skip to content
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

Pass typed plugin option data to plugin in init #3582

Merged
merged 7 commits into from
Mar 10, 2020

Conversation

niftynei
Copy link
Collaborator

@niftynei niftynei commented Mar 8, 2020

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.

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?
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
Copy link
Collaborator

@darosior darosior left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"]:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[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..

@rustyrussell rustyrussell merged commit 41b1805 into ElementsProject:master 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, "")) {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants