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

Make handleValidatorExitCommand work with REST API #3318

Merged
merged 1 commit into from
Jan 25, 2022

Conversation

EmilIvanichkovv
Copy link
Contributor

No description provided.

@github-actions
Copy link

Unit Test Results

     12 files  ±0     790 suites  ±0   36m 22s ⏱️ - 3m 51s
1 615 tests ±0  1 567 ✔️ ±0    48 💤 ±0  0 ±0 
9 509 runs  ±0  9 405 ✔️ ±0  104 💤 ±0  0 ±0 

Results for commit 0155014. ± Comparison against base commit d076e1a.

@zah zah merged commit efbd939 into status-im:unstable Jan 25, 2022
@@ -333,37 +333,37 @@ proc check_voluntary_exit*(

# Not in spec. Check that validator_index is in range
if voluntary_exit.validator_index >= state.validators.lenu64:
return err("Exit: invalid validator index")
return err("Invalid validator index")
Copy link
Member

Choose a reason for hiding this comment

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

the state transition has a convention to include where the error is coming from - voluntary exit processing shoud not deviate from it, this needs to be changed back

Copy link
Contributor

Choose a reason for hiding this comment

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

I think this was done to provide a more reasonable message as an error output of the REST API, but it can be handled locally there (which would be admittedly a bit hacky). A more proper engineering solution would be to replace these strings with an enum.

Copy link
Member

Choose a reason for hiding this comment

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

well, I'd prefer that the state transition stays clean - the rest api error outputs aren't hurt by an extra "exit", but the we use these strings in other places as well where it makes sense in their context that they're formatted the way they are (for example when dealing with invalid blocks) - this is more important than rest error messages.

Copy link
Member

Choose a reason for hiding this comment

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

The broader point here is that the convention exists for a reason (it wasn't put there frivolously): when starting to use the functions in a new context, that reason must be taken into account so that the old functionality doesn't regress: there are two ways to approach that:

  • adapt the new functionality to the current status quo
  • change the current status quo to be fully consistent with both the new use cases and the old use cases

Either is fine, but leaving the code half-way broken is not.

@arnetheduck
Copy link
Member

This change needs a corresponding update to the manual: previously we required running the node with json-rpc enabled - now it will be REST instead.

@@ -542,16 +542,16 @@ type
name: "validator"
desc: "Validator index or a public key of the exited validator" }: string

rpcUrlForExit* {.
Copy link
Member

Choose a reason for hiding this comment

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

this command line parameter should remain: when someone uses it, a warning should be printed pointing to the new option.

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