Mercurial: Changelog

debugcommands: support for triggering push protocol The mechanism for pushing to a remote is a bit more complicated than other commands. On SSH, we wait for a positive reply from the server before we start sending the bundle payload. This commit adds a mechanism to the "command" action in `hg debugwireproto` to trigger the "push protocol" and to specify a file whose contents should be submitted as the command payload. With this new feature, we implement a handful of tests for the "unbundle" command. We try to cover various server failures and hook/output scenarios so protocol behavior is as comprehensively tested as possible. Even with so much test output, we only cover bundle1 with Python hooks. There's still a lot of test coverage that needs to be implemented. But this is certainly a good start. Because there are so many new tests, we split these tests into their own test file. In order to make output deterministic, we need to disable the doublepipe primitive. We add an option to `hg debugwireproto` to do that. Because something in the bowels of the peer does a read of stderr, we still capture read I/O from stderr. So there is test coverage of what the server emits. The tests around I/O capture some wonkiness. For example, interleaved ui.write() and ui.write_err() calls are emitted in order. However, (presumably due to buffering), print() to sys.stdout and sys.stderr aren't in order. We currently only test bundle1 because bundle2 is substantially harder to test because it is more complicated (the server responds with a stream containing a bundle2 instead of a frame). Differential Revision: https://phab.mercurial-scm.org/D2471

sshpeer: support not reading and forwarding stderr The "doublepipe" primitive as used by sshpeer will automatically read from stderr and forward output to the local ui. This poses problems for deterministic testing because reads may not be consistent. For example, the server may not be done sending all output to stderr and the client will perform different numbers of read operations or will read from stderr and stdout at different times. To make tests deterministic, we'll need to disable the "doublepipe" primitive and perform stderr I/O explicitly. We add an argument to the sshpeer constructor to disable the use of the doublepipe. Differential Revision: https://phab.mercurial-scm.org/D2467

tests: add wire protocol tests for pushkey Let's get the wire format of some pushkey requests in test-ssh-proto.t. Differential Revision: https://phab.mercurial-scm.org/D2466

debugcommands: support for sending "batch" requests Let's teach `hg debugwireproto` to send "batch" requests. The easiest way to implement this was as a pair of instructions to begin and end a batched operation. Otherwise, we would have to reinvent the parsing wheel or factor out the parsing code. To prove it works, we add a batched request to test-ssh-proto.t. Differential Revision: https://phab.mercurial-scm.org/D2408

debugcommands: allow sending of simple commands with debugwireproto Previously, we only had support for low-level "raw" operations. A goal of `hg debugwireproto` is to allow easily performing higher-level primitives, such as sending a wire protocol command and reading its response. We implement a "command" action that does just this. Currently, we only support simple commands (those without payloads). We have basic support for sending command arguments. We don't yet support sending dictionary arguments. This will be implemented later. To prove it works, we add tests to test-ssh-proto.t that send some "listkeys" commands. Note: we don't observe/report os.read() events because these may not be deterministic. We instead observe/report the read() and readline() operations on the bufferedinputpipe. These *should* be deterministic. Differential Revision: https://phab.mercurial-scm.org/D2406

wireproto: sort response to listkeys The listkeys protocol is defined to produce a dictionary. pushkey.decodekeys() uses a plain dict to hold the decoded results of the wire protocol response. So order should not matter. Upcoming tests will verify low-level output of wire protocol commands and the non-deterministic emitting of listkeys was causing intermittent failures. So we make the output of listkeys deterministic. Differential Revision: https://phab.mercurial-scm.org/D2405

debugcommands: add debugwireproto command We currently don't have a low-level mechanism for sending arbitrary wire protocol commands. Having a generic and robust mechanism for sending wire protocol commands, examining wire data, etc would make it vastly easier to test the wire protocol and debug server operation. This is a problem I've wanted a solution for numerous times, especially recently as I've been hacking on a new version of the wire protocol. This commit establishes a `hg debugwireproto` command for sending data to a peer. The command invents a mini language for specifying actions to take. This will enable a lot of flexibility for issuing commands and testing variations for how commands are sent. Right now, we only support low-level raw sends and receives. These are probably the least valuable commands to intended users of this command. But they are the most useful commands to implement to bootstrap the feature (I've chosen to reimplement test-ssh-proto.t using this command to prove its usefulness). My eventual goal of `hg debugwireproto` is to allow calling wire protocol commands with a human-friendly interface. Essentially, people can type in a command name and arguments and `hg debugwireproto` will figure out how to send that on the wire. I'd love to eventually be able to save the server's raw response to a file. This would allow us to e.g. call "getbundle" wire protocol commands easily. test-ssh-proto.t has been updated to use the new command in lieu of piping directly to a server process. As part of the transition, test behavior improved. Before, we piped all request data to the server at once. Now, we have explicit control over the ordering of operations. e.g. we can send one command, receive its response, then send another command. This will allow us to more robustly test race conditions, buffering behavior, etc. There were some subtle changes in test behavior. For example, previous behavior would often send trailing newlines to the server. The new mechanism doesn't treat literal newlines specially and requires newlines be escaped in the payload. Because the new logging code is very low level, it is easy to introduce race conditions in tests. For example, the number of bytes returned by a read() may vary depending on load. This is why tests make heavy use of "readline" for consuming data: the result of that operation should be deterministic and not subject to race conditions. There are still some uses of "readavailable." However, those are only for reading from stderr. I was able to reproduce timing issues with my system under load when using "readavailable" globally. But if I "readline" to grab stdout, "readavailable" appears to work deterministically for stderr. I think this is because the server writes to stderr first. As long as the OS delivers writes to pipes in the same order they were made, this should work. If there are timing issues, we can introduce a mechanism to readline from stderr. Differential Revision: https://phab.mercurial-scm.org/D2392

debugcommands: add debugserve command `hg serve --stdio` requires the exact command argument form `hg -R <path> serve --stdio` for security reasons. An upcoming commit will need to start an SSH protocol server process with custom settings. This commit creates a `hg debugserve` command for starting servers with custom options. There are no security restrictions and we can add options here that aren't appropriate for built-in commands. We currently only support starting an SSH protocol server using the process's stdio file descriptors. The server supports logging its I/O activity to a file descriptor number passed as a command argument. Differential Revision: https://phab.mercurial-scm.org/D2464

wireprotoserver: support logging SSH server I/O to a file descriptor We will soon introduce a debug command and tests for low-level I/O behavior of the SSH wire protocol. To facilitate this, we need to instrument the SSH server so it can log its I/O as events occur. We teach the SSH server to convert its stdout and stderr file objects into file object proxies. We configure these proxies to log to a file descriptor whose file number is specified via a config option. The idea is to have a future debug command start the SSH server process with access to an extra file descriptor that can be used by the server process to log I/O. Monitoring only the write I/O will be more robust than monitoring both writes and reads from the client process because read operations are not deterministic. This will matter for tests that capture raw I/O activity. Differential Revision: https://phab.mercurial-scm.org/D2463

util: enable observing of util.bufferedinputpipe Our file object proxy is useful. But it doesn't capture all I/O. The "os" module offers low-level interfaces to various system calls. For example, os.read() exposes read(2) to read from a file descriptor. bufferedinputpipe is special in a few ways. First, it acts as a proxy of sorts around our [potentially proxied] file object. In addition, it uses os.read() to satisfy all I/O. This means that our observer doesn't see notifications for reads on this type. This is preventing us from properly instrumenting reads on ssh peers. This commit teaches bufferedinputpipe to be aware of our observed file objects. We do this by introducing a class variation that notifies our observer of os.read() events. Since read() and readline() bypass os.read(), we also teach this instance to notify the observer for buffered variations of these reads as well. We don't report them as actual read() and readline() calls because these methods are never called on the actual file object but rather a buffered version of it. We introduce bufferedinputpipe.__new__ to swap in the new class if the passed file object is a fileobjectproxy. This makes hooking up the observer automatic. And it is a zero cost abstraction for I/O operations on non-proxied file objects. Differential Revision: https://phab.mercurial-scm.org/D2404