WIP: Add test coverage for ConnectStream

[xyzconstant]

ref: #183

Opening this draft to make it visible to more reviewers. Quoting my comment in the issue as well:

I've added tests for four scenarios:

1. Attempting to use an fd associated with a server that has already been disconnected results in a crash with: "IPC client method called after disconnect".
2. Attempting to use an fd associated with a server that disconnects immediately after the first recv(), the outcome will either be crashing with "IPC client method called after disconnect" or "IPC client method call interrupted by disconnect." This behavior seems to depend on whether the recv() call successfully reads the entirety of what is likely Capnp’s bootstrap request or only a portion of it.
3. Attempting to use an fd associated with a server that disconnects after a second recv(), the process crashes with "IPC client method call interrupted by disconnect."
4. Attempting to use an fd associated with a server that indefinitely calls recv() in a while loop results in the test getting stuck at this line:

libmultiprocess/include/mp/proxy-types.h

Line 754 in 8412fcd

thread_context.waiter->wait(lock, [&done]() { return done; });

It’s important to note that all of these cases call FooInterface::initThreadMap() to invoke clientInvoke(), as ConnectStream() on its own won't trigger any libmultiprocess request if there's not a construct() method available in the Init interface.

I'm looking for more ideas for testing ConnectStream.

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline and AI policy for information on the review process.
A summary of reviews will appear here.

Conflicts

No conflicts as of last run.

[ryanofsky]

Thanks for following up to #183 with these tests. They do seem potentially useful. Here is feedback I'd have:

• The first 3 tests seems like they are mostly in good shape. You would just want to wrap these in try/catch to and assert expected exceptions are thrown. For the second test it would seem fine to accept both "called after disconnect" and "interrupted by disconnect" exceptions since we already have existing tests testing for each of these errors more specifically.

• The first 3 tests do overlap a lot with disconnect tests already in test.cpp, and it's a little questionable if having all 3 tests adds much value. The first test could be is nice because it directly tests connecting to a non-capnp server that disconnects ignoring whatever is sent. But the second and third tests just sending the same disconnect at later points in time and needing MSG_PEEK complexity would not seem to add as much value.

• For the 4th test having the client hang as long as server hangs is probably expected behavior. It would be good to make sure that client can still disconnect or cancel the calls if the the server hangs. Or that client calls are able to time out correctly.

• It could make sense to rebase this on #269 or rebase if that could help with the "Add the case with an actual mkdtemp/socket/bind/listen setup" follow up comment.

• Maybe (not sure) it could be interesting to have tests working in opposite direction with server providing dummy interface and clients connecting and disconnecting suddenly. Maybe it could also be useful to have tests sending garbage bytes and making sure clients and servers handle them cleanly. It might even be useful to use fuzzing for this though it might not be a good use of fuzzing resources since it would mostly only be fuzz testing capnproto code and only a little bit of libmultiprocess exception/cleanup handling code.

Overall the tests here seem reasonable to add. It seems good to have at least 1-2 tests verifying disconnects are processed when a capnproto client connects to a non-capnproto server.

(Relatedly, there are also other disconnect tests that could be added at different points during capnproto connections, which I started to write in #201 (comment) and https://github.com/ryanofsky/libmultiprocess/commits/pr/distest.2 but was never able to really finish due to complexity of trying to set up and cover all of the relevant cases. Just mentioning this for completeness, though. There's probably not an obviously place to follow up with this at the moment.)

[DrahtBot]

🐙 This pull request conflicts with the target branch and needs rebase.