test_get_network_status fails

[neena]

test_get_network_status fails intermittently with output like...

======================================================================
ERROR: test_get_network_status
----------------------------------------------------------------------
Traceback:
  File "/home/neena/code/stem/test/integ/control/controller.py", line 525, in test_get_network_status
    self.assertEqual(first_descriptor, controller.get_network_status(first_descriptor.fingerprint))
  File "/home/neena/code/stem/stem/control.py", line 723, in get_network_status
    desc_content = self.get_info(query)
  File "/home/neena/code/stem/stem/control.py", line 635, in get_info
    if default == UNDEFINED: raise exc
InvalidArguments: GETINFO request contained unrecognized keywords: ns/id/0013D22389CD50D0B784A3E4061CB31E8CE8CEB5


----------------------------------------------------------------------
Ran 19 tests in 0.280s

FAILED

Shutting down tor... done
TESTING FAILED (14 seconds)
  [RUN_OPEN] test_get_network_status (test.integ.control.controller.TestController) ... ERROR

[atagar]

Blarg! Stem's test is reading your cached-consensus, getting the first relay with a nickname other than 'Unnamed', then querying for that via GETINFO. I'm not sure why the GETINFO query would fail for something that's in your cached consensus.

Nick, any thoughts?

[atagar]

Hi Ravi. Are you still encountering this? If so then please send me the tar of your 'stem/test/data' directory so i can attempt to repro it.

[neena]

Stem test data dir

[neena]

Replying to atagar:

Hi Ravi. Are you still encountering this? If so then please send me the tar of your 'stem/test/data' directory so i can attempt to repro it.

Still do, about once in two dozen times.
I attached a tarball of my test/data directory after the test run where it failed.

[atagar]

Hmmm, I dropped write permissions so our tor instance wouldn't replace the consensus that had an issue (chmod -w test/data/cached-*), then tested with both v0.2.1.30 (once) and v0.2.3.16 (eight times). No luck.

I could make the test check for multiple relays which would hopefully make it more resilient, but that feels a bit a hack. As I understand it the cached-* files really should be a reflection of tor's perception of the network (and hence match what it responds to GETINFO queries with).

One other thought is that maybe your tor instance is using the cached-microdesc-consensus rather than cached-consensus (honestly I find the behavior around microdescriptors a bit confusing). We could check the first entry of both files.

Thoughts?

[atagar]

I just ran into this with test_get_server_descriptor...

======================================================================
                    test.integ.control.controller                     
======================================================================

test_authenticate                                            [SUCCESS]
test_enable_feature                                          [SUCCESS]
test_extendcircuit (requires online target)                  [SKIPPED]
test_from_port                                               [SUCCESS]
test_from_socket_file                                        [SUCCESS]
test_get_network_status                                      [SUCCESS]
test_get_network_statuses                                    [SUCCESS]
test_get_server_descriptor                                   [FAILURE]
test_get_server_descriptors                                  [SUCCESS]
test_get_version                                             [SUCCESS]
test_getconf                                                 [SUCCESS]
test_getinfo                                                 [SUCCESS]
test_loadconf                                                [SUCCESS]
test_mapaddress (requires online target)                     [SKIPPED]
test_protocolinfo                                            [SUCCESS]
test_repurpose_circuit (requires online target)              [SKIPPED]
test_saveconf                                                [SUCCESS]
test_set_conf                                                [SUCCESS]
test_signal                                                  [SUCCESS]

======================================================================
ERROR: test_get_server_descriptor
----------------------------------------------------------------------
Traceback:
  File "/home/atagar/Desktop/stem/test/integ/control/controller.py", line 462, in test_get_server_descriptor
    self.assertEqual(first_descriptor, controller.get_server_descriptor(first_descriptor.nickname))
  File "/home/atagar/Desktop/stem/stem/control.py", line 694, in get_server_descriptor
    desc_content = self.get_info(query)
  File "/home/atagar/Desktop/stem/stem/control.py", line 647, in get_info
    if default == UNDEFINED: raise exc
InvalidArguments: GETINFO request contained unrecognized keywords: desc/name/FastTmpRelay


----------------------------------------------------------------------
Ran 19 tests in 5.712s

FAILED

This is a bit puzzling. The relay can be fetched by its fingerprint but not nickname. It's in most of my cached files...

atagar@morrigan:~/Desktop/stem$ grep FastTmpRelay test/data/cached-*
test/data/cached-consensus:r FastTmpRelay Ku0Bh15lr17BH3VdmLqWGnS0wTE /v7SAW6PPEo2rA9X0fPJhj93JIc 2012-11-16 20:15:49 178.216.201.51 443 0
test/data/cached-descriptors:router FastTmpRelay 178.216.201.51 443 0 0
test/data/cached-extrainfo:extra-info FastTmpRelay 2AED01875E65AF5EC11F755D98BA961A74B4C131
test/data/cached-microdesc-consensus:r FastTmpRelay 2/dW/EuJxkK3je+EFGq97M7+34M 2012-11-04 18:26:34 178.216.201.51 443 0

This doesn't include cached-microdescs so maybe we need to only use relays in that. However, we don't have microdescriptor parsing yet and that still feels like a hack so we should get a better understanding of this first.

For now I'm disabling that part of both tests since they're clearly buggy...

​https://gitweb.torproject.org/stem.git/commitdiff/e73c4f353612ad26b47ca2c66d8c6f4ac78f165b

[atagar]

Finally fixed...

​https://gitweb.torproject.org/stem.git/commitdiff/db19cafb398e9626502cf9d1226803a5fb4cb4b1