This PR adds a depends patch to fix a Cap'n Proto bug present in macOS that throws the following exception after accepting a disconnected client:
mp/proxy.cpp:48: error: Uncaught exception in daemonized task.; exception = kj/async-io-unix.c++:1365: failed: setsocketopt(IPPROTO_TCP, TCP_NODELAY): Invalid argument
This goes uncaught killing libmultiprocess's accept loop (mp::ListenConnections()) in the process.
Root cause
After accept(), kj unconditionally calls setsockopt(TCP_NODELAY) on the connection socket. For Unix sockets, kj handles the usual "not supported" error codes, however, on macOS EINVAL is returned when the client has already disconnected and kj only tolerates that code when built for FreeBSD. The unexpected error then goes uncaught in the accept loop, causing the listener to stop accepting new connections.
See https://github.com/bitcoin-core/libmultiprocess/issues/319 for more details and instructions on how to reproduce it in Bitcoin Core using socat.
Fix
The patch is based on the EINVAL handling from capnproto/capnproto@7df5bd078, which is only available on the not yet released v2 branch. It's applied to capnp.mk as a temporary workaround until capnproto/capnproto#2748 is available in a v1 release.
<!-- *** Please remove the following help text before submitting: *** Pull requests may be closed immediately if they: - do not have a rationale and clear improvement - do not adhere to doc/AI_POLICY.md GUI-related pull requests should be opened against https://github.com/bitcoin-core/gui first. See CONTRIBUTING.md -->
<!-- Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly: * Any test improvements or new tests that improve coverage are always welcome. * All other changes should have accompanying unit tests (see `src/test/`) or functional tests (see `test/`). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change. * Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed. * Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible. * Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most "code style" refactoring changes require a thorough explanation why they are useful, what downsides they have and why they *significantly* improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the [developer notes](/doc/developer-notes.md), stylistic code changes are usually rejected. -->
<!-- Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. -->
