unicode error in _got_announcement at startup #2817

New Issue

warner · 2016-09-01T21:17:31Z

warner commented

2016-09-01 21:17:31 +00:00

user "Vladislav" on the mailing list reported an exception when starting a node with an I2P-based client:

>  File "/home/vlad/.virtualenvs/tahoe/local/lib/python2.7/site-packages/foolscap/eventual.py",
> line 26, in _turn
>    cb(*args, **kwargs)
>  File "/home/vlad/tahoe-lafs/src/allmydata/storage_client.py", line 144, in _got_announcement
>    precondition(isinstance(key_s, str), key_s)
>  File "/home/vlad/tahoe-lafs/src/allmydata/util/assertutil.py", line 39, in precondition
>    raise AssertionError, "".join(msgbuf)
> exceptions.AssertionError: precondition: u'v0-myl4clrthvchbjn77vkojeadtaprngcubxuyjxcfimyb6irvdola' <type 'unicode'>

This looks like we're feeding a unicode key_s server-identifier into a function that really wants a string. There are two pathways into _got_announcement(): one is when the IntroducerClient receives a new announcement, the other is at startup when the IntroducerClient is reading the introducer_cache.yaml entries and delivering them as if they were real-time announcements.

I suspect that this is the second case, and we're missing code to string-ify the server-id values on the way in.

user "Vladislav" on the mailing list reported an exception when starting a node with an I2P-based client: ``` > File "/home/vlad/.virtualenvs/tahoe/local/lib/python2.7/site-packages/foolscap/eventual.py", > line 26, in _turn > cb(*args, **kwargs) > File "/home/vlad/tahoe-lafs/src/allmydata/storage_client.py", line 144, in _got_announcement > precondition(isinstance(key_s, str), key_s) > File "/home/vlad/tahoe-lafs/src/allmydata/util/assertutil.py", line 39, in precondition > raise AssertionError, "".join(msgbuf) > exceptions.AssertionError: precondition: u'v0-myl4clrthvchbjn77vkojeadtaprngcubxuyjxcfimyb6irvdola' <type 'unicode'> ``` This looks like we're feeding a unicode `key_s` server-identifier into a function that really wants a string. There are two pathways into `_got_announcement()`: one is when the IntroducerClient receives a new announcement, the other is at startup when the IntroducerClient is reading the `introducer_cache.yaml` entries and delivering them as if they were real-time announcements. I suspect that this is the second case, and we're missing code to string-ify the server-id values on the way in.

warner added the

labels 2016-09-01 21:17:31 +00:00

warner added this to the 1.12.0 milestone 2016-09-01 21:17:31 +00:00

warner commented

2016-09-02 02:30:51 +00:00

patch in https://github.com/tahoe-lafs/tahoe-lafs/pull/329 , waiting for tests to run now

patch in <https://github.com/tahoe-lafs/tahoe-lafs/pull/329> , waiting for tests to run now

Brian Warner <warner@lothar.com> commented

2016-09-02 04:21:35 +00:00

In a1594df0/trunk:

introclient: only give ascii key_s to storagebroker

This was triggered when the initial Introducer connection failed, so the
node read the introducer_cache.yaml from disk. That always returns
unicode strings, and the StorageFarmBroker insisted that it's
server-IDs (aka "key_s") were bytestrings.

The tests were extended to exercise the code that loads from disk and
delivers to the StorageFarmBroker, and more preconditions were put in
place to catch this sort of thing earlier next time.

closes ticket:2817

In [a1594df0/trunk](/tahoe-lafs/trac-2024-07-25/commit/a1594df0a64972b957f0a1ccf10d6efcf0386059): ``` introclient: only give ascii key_s to storagebroker This was triggered when the initial Introducer connection failed, so the node read the introducer_cache.yaml from disk. That always returns unicode strings, and the StorageFarmBroker insisted that it's server-IDs (aka "key_s") were bytestrings. The tests were extended to exercise the code that loads from disk and delivers to the StorageFarmBroker, and more preconditions were put in place to catch this sort of thing earlier next time. closes ticket:2817 ```

tahoe-lafs added the

fixed

label 2016-09-02 04:21:35 +00:00

tahoe-lafs closed this issue

2016-09-02 04:21:35 +00:00

Sign in to join this conversation.