Opened 8 years ago

Closed 7 years ago

#7163 closed defect (fixed)

test_get_network_status fails

Reported by: neena Owned by: neena
Priority: Medium Milestone:
Component: Archived/Stem Version:
Severity: Keywords: testing
Cc: atagar Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


test_get_network_status fails intermittently with output like...

ERROR: test_get_network_status
  File "/home/neena/code/stem/test/integ/control/", line 525, in test_get_network_status
    self.assertEqual(first_descriptor, controller.get_network_status(first_descriptor.fingerprint))
  File "/home/neena/code/stem/stem/", line 723, in get_network_status
    desc_content = self.get_info(query)
  File "/home/neena/code/stem/stem/", 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


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

Child Tickets

Attachments (1)

data.tar.gz (1.7 MB) - added by neena 8 years ago.
Stem test data dir

Download all attachments as: .zip

Change History (8)

comment:1 Changed 8 years ago by 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?

comment:2 Changed 8 years ago by atagar

Status: newneeds_information

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.

Changed 8 years ago by neena

Attachment: data.tar.gz added

Stem test data dir

comment:3 in reply to:  2 Changed 8 years ago by neena

Status: needs_informationassigned

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.

comment:4 Changed 8 years ago by atagar

Owner: changed from atagar to neena

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.


comment:5 Changed 8 years ago by atagar

Keywords: testing added

comment:6 Changed 8 years ago by atagar

I just ran into this with test_get_server_descriptor...


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
  File "/home/atagar/Desktop/stem/test/integ/control/", line 462, in test_get_server_descriptor
    self.assertEqual(first_descriptor, controller.get_server_descriptor(first_descriptor.nickname))
  File "/home/atagar/Desktop/stem/stem/", line 694, in get_server_descriptor
    desc_content = self.get_info(query)
  File "/home/atagar/Desktop/stem/stem/", 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


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 443 0
test/data/cached-descriptors:router FastTmpRelay 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 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...

comment:7 Changed 7 years ago by atagar

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.