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

Update shh module & relocate to parity and geth namespaces #1308

Merged
merged 5 commits into from
Apr 5, 2019

Conversation

njgheorghita
Copy link
Contributor

@njgheorghita njgheorghita commented Mar 29, 2019

What was wrong?

  • Updated Shh module to V2
  • Exposed supported Whisper endpoints in GethShh and ParityShh
  • Hooked up integration tests for supported endpoints for geth and parity

Cute Animal Picture

image

@njgheorghita njgheorghita force-pushed the relocate-shh-module branch 12 times, most recently from 74fb1b5 to 7f1d7d0 Compare March 29, 2019 18:23
web3/shh.py Outdated
return self.web3.manager.request_blocking("shh_hasKeyPair", [id])
def post_munger(module, message):
if message and ("payload" in message):
return (message,)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@dylanjw I'm not sure if this is a misunderstanding on my end or a bug with the munger, but this was the only way I could successfully use this munger. From what I understand this should return something like return module, [message] - but that wouldn't work.

Copy link
Contributor

Choose a reason for hiding this comment

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

mungers only need to return the arguments, and not the module object. This was changed, and it looks like I didnt update the docstring in the Method class.

So what you have here is correct.

docs/web3.shh.rst Outdated Show resolved Hide resolved
web3/parity.py Outdated
"""
https://wiki.parity.io/JSONRPC-shh-module
"""
info = info()
Copy link
Contributor

Choose a reason for hiding this comment

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

It might be clearer if these methods were just assigned to variable names, rather than the output of these functions. info = Method(...) and then class attribute assignment could lose the parens. info = info.

web3/shh.py Outdated
)
from web3.module import (
Module,
from web3.method import (
Copy link
Contributor

Choose a reason for hiding this comment

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

It might be good to move this whole file to utils now, since nothing in here works without being assigned to a module. People might think that web3.ssh.* is part of the api.

Copy link
Member

Choose a reason for hiding this comment

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

If we're going to do it that way, the mungers property on the Method class needs to be converted to a tuple as well as auditing it for any other mutable properties to ensure that modifications to a Method object don't have unintended side effects.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

as well as auditing it for any other mutable properties to ensure that modifications to a Method object don't have unintended side effects.

Can you explain this a little further - what are some potential side effects? what are the other mutable properties we should check?

web3/shh.py Outdated
return self.web3.manager.request_blocking("shh_hasKeyPair", [id])
def post_munger(module, message):
if message and ("payload" in message):
return (message,)
Copy link
Contributor

Choose a reason for hiding this comment

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

mungers only need to return the arguments, and not the module object. This was changed, and it looks like I didnt update the docstring in the Method class.

So what you have here is correct.

@@ -239,7 +239,8 @@ def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)

def get_new_entries(self):
log_entries = self._filter_valid_entries(self.web3.shh.getMessages(self.filter_id))
all_messages = self.web3.parity.shh.getFilterMessages(self.filter_id)
Copy link
Member

Choose a reason for hiding this comment

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

This seems wrong that this is accessing the primary w3.parity module.

web3/_utils/module_testing/shh_module.py Show resolved Hide resolved
topic = '0x13370000'
payloads = [web3.toHex(text="test message :)"), web3.toHex(text="2nd test message")]

shh_filter_id = web3.parity.shh.newMessageFilter({
Copy link
Member

Choose a reason for hiding this comment

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

There seems to be a lot of similarity between these two implementations (geth and parity) of the tests. Thoughts on trying to collapse these into something a little more DRY?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'd like to, but imo they aren't as similar as they may appear. Besides the different shh modules being tested against, the way parity implements post, newMessageFilter, info and version all differ in the params accepted by the jsonrpc endpoint, and the type of data returned. The only tests that are the same are test_shh_asymmetric_key_pair and test_shh_symmetric_key_pair. Beyond that it seems to me like sharing tests might require a fair amount of config overhead that might end up more confusing

web3/geth.py Outdated Show resolved Hide resolved
web3/shh.py Outdated
)
from web3.module import (
Module,
from web3.method import (
Copy link
Member

Choose a reason for hiding this comment

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

If we're going to do it that way, the mungers property on the Method class needs to be converted to a tuple as well as auditing it for any other mutable properties to ensure that modifications to a Method object don't have unintended side effects.

@njgheorghita njgheorghita force-pushed the relocate-shh-module branch 4 times, most recently from d8e5710 to 750c90a Compare April 2, 2019 16:18
@njgheorghita njgheorghita force-pushed the relocate-shh-module branch 3 times, most recently from f0a9be1 to 174d816 Compare April 4, 2019 11:59
@njgheorghita
Copy link
Contributor Author

@pipermerriam @kclowes ping for final review.

Also, geth v1.7.2 integration tests just broke all of a sudden

ci.go:180: You have Go version go1.12.1
ci.go:181: go-ethereum requires at least Go version 1.7 and cannot
ci.go:182: be compiled with an earlier version. Please upgrade your Go installation.

Makes no sense to me why this happened, especially since geth v1.7.2 tests have been compiling happily with go1.12 ever since I updated the go version in #1301

Also raises the question, why are we running integration tests against geth 1.7.2 and 1.8.22? Is it fine to just drop the 1.7.2 tests as they're becoming more and more outdated?

@kclowes
Copy link
Collaborator

kclowes commented Apr 4, 2019

I am not sure why this just broke, but it's due to this line in 1.7. Apparently go1.12 is less than go1.7. I can't find how long they will support geth 1.7 (or if they even still are supporting 1.7?), but the last 1.7 release was Nov. 2017. So I guess I see 3 options:

  1. Downgrade the go version to 1.9 (which is unsupported) here
  2. Backport the fix that's in geth 1.8 to 1.7 (here)
  3. We drop integration tests for 1.7.
    Like I said, I don't have a good feel for how long Geth 1.7 will be supported or how many people are still using geth 1.7, so I'm not sure what the right answer is, but I think I would naively lean toward option 1 and/or 2. I could also be persuaded otherwise.

Copy link
Collaborator

@kclowes kclowes left a comment

Choose a reason for hiding this comment

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

🚀 Looks good to me @njgheorghita! Just left one typo comment.


.. py:method:: Shh.deleteKeyPair(self, id)

* Deletes the specifies key if it exists.
Copy link
Collaborator

Choose a reason for hiding this comment

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

*specified

@njgheorghita
Copy link
Contributor Author

njgheorghita commented Apr 5, 2019

@kclowes

Apparently go1.12 is less than go1.7.

where did you see that? I'm wholly unfamiliar with go haha - but that seems weird to me, also when it seems 1.12 is the latest release

@pipermerriam
Copy link
Member

What is the oldest version of go-ethereum that supports the mainnet?

@njgheorghita
Copy link
Contributor Author

@pipermerriam Not sure if I understand your question - but from what I can tell it's v1.0.0

This is the first major and first live-net version of the go-ethereum client geth (1.0.0) and marks a major milestone in the history of Ethereum and the Go Ethereum codebase.

@kclowes
Copy link
Collaborator

kclowes commented Apr 5, 2019

@njgheorghita I learned yesterday that you can compare strings in go. So in geth v1.7 they were comparing runtime.Version() < 'go1.7', where in our case runtime.Version() == go1.12. But because it's not comparing numbers, I think what's happening is that it compares the first 5 characters and returns true because go1.1 is less than go1.7. It looks like the geth team changed that line of code in version 1.8 though. So 1.12 is definitely the latest go release, there is just a bug in how geth1.7 checks the go version.

@pipermerriam
Copy link
Member

@kclowes you can do this type of string comparison (and make the same mistake) in python as well (I've done it)

@njgheorghita I was intending to mean the current mainnet. Basically, I'm wondering how useful it is for us to support any of the 1.7x line of go-ethereum

@pipermerriam
Copy link
Member

@njgheorghita ignore me, I now see this is the version of go, not goethereum

@kclowes
Copy link
Collaborator

kclowes commented Apr 5, 2019

@pipermerriam Interesting! I can see where it would be a useful feature.

I think our problem has just fixed itself. So ignore all of the above. Now I really don't know what was going on 😆

@njgheorghita
Copy link
Contributor Author

Pffft that's frustrating, but who cares it works!!

@njgheorghita njgheorghita force-pushed the relocate-shh-module branch 2 times, most recently from fad9241 to a489f61 Compare April 5, 2019 17:56
@njgheorghita njgheorghita merged commit cba9538 into ethereum:master Apr 5, 2019
@njgheorghita njgheorghita deleted the relocate-shh-module branch April 5, 2019 18:30
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.

4 participants