Adrian Duke bfb54bf4be e2e: Fix flakiness in test_connection_crossing test
Addresses intermittent failures in the `test_connection_crossing` e2e test,
which were particularly prevalent on slower CI environments (such as
`rust:trixie`).

Previously, the test spawned two threads to make Alice and Bob dial each
other concurrently and strictly asserted that the "preferred" peer (the
one with the higher Node ID) would always win the `Outbound` link direction.
However, this assumption is flawed in real-world, OS-level network execution
due to two race conditions:

1. Thread Scheduling: One thread could execute and fully establish a
   connection before the other thread even began processing its dial command.
2. Reactor Event Ordering: A node's reactor might wake up and process an
   incoming TCP connection from its peer *before* it processes the `Connect`
   command sent by the test. When it finally processes the `Connect` command,
   it sees a session already exists and skips dialing entirely.

In both scenarios, a true "simultaneous crossing" never occurs. Instead, a
standard sequential connection happens, meaning the link direction is dictated
by whoever dialed first, not by the "preferred" peer logic. This caused the
strict `left: Outbound, right: Inbound` assertions to panic.

To fix this, two changes were made:
- Introduced a `std::sync::Barrier` to synchronize the two test threads.
  This forces both threads to wait for each other before calling `.connect()`,
  maximizing the probability of a true simultaneous dial.
- Relaxed the final assertions. Because OS-level TCP handshakes and reactor
  polling can never guarantee perfect simultaneity, we no longer assert
  *which* peer gets the `Outbound` link. Instead, we assert the core invariant:
  that exactly one connection is established between the nodes, and that their
  link directions are opposite (`s1.link != s2.link`).
2026-04-23 08:39:03 +01:00
2024-05-17 13:27:18 +02:00
2023-12-13 12:25:12 +01:00
2026-02-19 21:02:22 +01:00
2026-02-16 08:33:58 +00:00
2024-04-29 10:47:03 +02:00
2025-05-15 14:54:13 +02:00
2025-04-17 14:33:36 +02:00
2026-03-30 16:57:51 +02:00
2026-04-17 17:15:31 +01:00
2024-04-03 15:32:26 +02:00
2026-04-15 10:06:05 +02:00
2022-11-16 12:26:12 +01:00
2025-12-08 16:43:50 +00:00
2026-02-18 09:50:16 +00:00
2026-04-17 17:15:31 +01:00
2025-07-16 16:54:43 +02:00
2026-02-13 13:34:11 +01:00
2024-04-29 10:47:03 +02:00

❤️🪵

Radicle Heartwood Protocol & Stack

Heartwood is the third iteration of the Radicle Protocol, a powerful peer-to-peer code collaboration and publishing stack. The repository contains a full implementation of Heartwood, complete with a user-friendly command-line interface (rad) and network daemon (radicle-node).

Radicle was designed to be a secure, decentralized and powerful alternative to code forges such as GitHub and GitLab that preserves user sovereignty and freedom.

See the Radicle home page for general information, and the Zulip chat to talk to the project.

See the Protocol Guide for an in-depth description of how Radicle works.

Installation

Requirements

  • Linux or Unix based operating system.
  • Git 2.34 or later
  • OpenSSH 9.1 or later with ssh-agent

📀 From binaries

Requires curl and tar.

Run the following command to install the latest binary release:

curl -sSf https://radicle.xyz/install | sh

Or visit our download page.

📦 From source

Requires the Rust toolchain.

You can install the Radicle stack from source, by running the following commands from inside this repository:

cargo install --path crates/radicle-cli --force --locked --root ~/.radicle
cargo install --path crates/radicle-node --force --locked --root ~/.radicle
cargo install --path crates/radicle-remote-helper --force --locked --root ~/.radicle

Or directly from our seed node:

cargo install --force --locked --root ~/.radicle \
    --git https://seed.radicle.xyz/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git \
    crates/radicle-cli crates/radicle-node crates/radicle-remote-helper

Running

Systemd unit files are provided for the node under the /systemd folder. They can be used as a starting point for further customization.

For running in debug mode, see HACKING.md.

Feedback

If you have feedback, feel free to create issues using rad issue, join our Zulip, or email feedback@radicle.xyz. Emails sent to this address are automatically posted to our public #feedback channel on Zulip, revealing the From header (which usually contains your name and email address). This allows us to discuss your feedback on Zulip, and, if necessary, respond to you via email.

Contributing

See CONTRIBUTING.md and HACKING.md for an introduction to contributing to Radicle.

License

Radicle is distributed under the terms of both the MIT license and the Apache License (Version 2.0).

See LICENSE-APACHE and LICENSE-MIT for details.

S
Description
Radicle Heartwood Protocol & Stack
Readme
40 MiB
Languages
Rust 97.8%
Shell 0.5%
CUE 0.4%
Nix 0.3%
Just 0.3%
Other 0.6%