The Mailbox object throws CrowdedError, but WebSocketRendezvous wasn't
handling it specifically. The server responded by dropping the connection and
logging an "Unhandled Error", so the client would reconnect and then get the
same error again and again.
This changes WebSocketRendezvous to handle CrowdedError by sending a
"crowded" error response. The client should react to this by giving up on the
connection entirely, and not reconnecting.
We only log the internal (sqlite) ID of the nameplate, not the actual
small-integer name. While investigating misbehavior due to overload, I was
confused into thinking that users were getting nameplates in the 15000+
range, when in fact those were merely the internal database row ids.
With this change it's easier to automate the continuous delivery of the snap, because when a verified tag is pushed to the repo the snap will get that version. There will be no need to manually change the version in the snapcraft.yaml.
This now shares the _compose() decorator with wormhole.cli.cli, and removes
the arguments_to_config() function in favor of just copying all kwargs into
the Config object.
The previous behavior was to throw an Automat exception, when a state machine
was given a LOST event from the initial non-connected state, and it didn't
have a handler for it. This version throws ServerConnectionError instead.
Still needs a test
refs #180
"wormhole-server restart" was broken by the addition of --disallow-list,
because the Click parser wasn't update to include the argument. This test
should exercise that a basic no-argv invocation of both "start" and "restart"
can at least build the Service object successfully.
refs #151
This adds no additional dependencies (txtorcon only depends on things that we
already depend upon anyways), and txtorcon itself is only 300kB. This removes
the need for using `pip install magic-wormhole[tor]` to get Tor support:
instead, just dod `pip install magic-wormhole`.
closes#174
This provides a clear error in case the user doesn't have an internet
connection at all, or something is so broken with their DNS or routing that
they can't reach the server. I think this is better than waiting and
retrying (silently) forever.
If the first connection succeeds, but is then lost, subsequent retries occur
without fanfare.
closes#68
