I've seen intermittent failures in
test_cli.PregeneratedCode.test_text_subprocess where the host was slow (or
overloaded) enough that the "Waiting for sender.." pacifier message was
displayed, which flunks the test because we're looking for a specific output
string. We patch this 1-second timer in the non-subprocess tests, but you
can't patch across a process boundary.
This patch adds an undocumented environment variable that lets you override
the timer values. The test then sets it to something large.
For future consideration: another approach would be to change the test to
tolerate the extra message. This would be trickier to validate, though.
A slow Travis-CI host caused one the 1.0s KEY_TIMER to fire by accident,
making the test fail because it wasn't expecting to see the "please be
patient" message. Fixed this by increasing the timeout to a very large value
when we aren't explicitly testing it.
A tiny update to show the command to execute along with the code required on
the same line, rather than split across two lines. This small change helps
when sending the information to others using copy and paste.
Fixes#266
-=david=-
This ought to help with #251, where bash-on-windows makes it easy to add a
forward-slash, and os.path.normpath() knows how to remove them, but os.sep is
a backslash.
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 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
This shifts most reponsibility to the new txtorcon "Controller" object, where
it belongs. We no longer need a list of likely control-port locations, nor do
we need to keep track of the SOCKS port ourselves.
The one downside is that if a control-port is not reachable, then this does
not fall back to using a plain SOCKS port (usually tcp:localhost:9050).
txtorcon no longer uses txsocksx, so it no longer advertises a simple way to
use Tor without the control port. This shouldn't affect users who run the
TorBrowserBundle, or who are running a tor daemon which they can control
directly, but it may break for users who want to use a pre-existing tor
daemon that they don't have permissions to speak control-port to.
This renames all the existing API methods, to use a consistent
"d=get_XYZ()" (for Deferred mode) or "dg.wormhole_got_XYZ()" (for Delegated
mode). It updates cmd_send/cmd_receive/cmd_ssh to use the new API.
Since we now have get_welcome(), apps handle the Welcome message with a
Deferred callback instead of registering a "welcome handler". This lets us
make sure we've finished printing any server message-of-the-day or "you
should update your client" message to stdout before using stdio to ask for
the wormhole code. (Previously, the code-input prompt was overwritten by the
server message, and it was ugly). refs #145. This approach adds an extra
roundtrip to the receiver, but we can fix that (see #145 for details).
Because of that change, the server-is-being-slow message is printed at a
slightly different time, so those tests needed some extra work to exercise it
properly.
I think we're better off without this: the CLI commands propagate the Failure
up to their callers (rather than eating it silently), the callers are using
task.react (which reacts to Failures by exiting with rc!=0), so nothing
should get lost. And doing an extra log.err() just creates more cleanup work
for test cases to flush, and makes the CLI commands double-print the any
errors (maybe task.react also points logging at stderr?).
The Welcome class prints a message if the server recommends a CLI version
that's newer than what the client is currently using, but only if the client
is running a "release" version, not a "local" development one. "local"
versions have a "+" in them (at least when Versioneer creates it), but
Welcome was looking for "-" as an indicator. So it was printing the warning
when it shouldn't be.
re-enable the test, and add an extra one
The comments in cmd_send/cmd_receive now enumerate the four cases where we
might notice that things are taking too long, the three cases where we say
something about it, and the two cases where it might be appropriate to give
up automatically (although we don't do that anywhere yet).
