Commit Graph

5 Commits

Author SHA1 Message Date
Lorenz Leutgeb 5bc2dc677b repo: Move workspace crates into `crates` subdirectory
This keeps the top level of the repo cleaner, e.g.
<https://github.com/radicle-dev/heartwood> scrolls less and
<https://app.radicle.xyz/nodes/rosa.radicle.xyz/rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5/>
might show more files at the top level.

This way we also don't have to explicitly name all crates in
`Cargo.toml`.
2025-06-09 15:09:21 +02:00
Fintan Halpenny 5b4cbc2cd8 radicle: introduce announcer
Similar to the `Fetcher` sans-IO approach, an `Announcer` sans-IO approach is
introduced. The previous `Handler::announce` was already quite close to using a
sans-IO approach, but using internally held state. This change makes the
business logic more reusable – and testable.

Similarly to the `Fetcher`, the `Announcer` is configured and then driven by
telling it when nodes have been synchronized with. It will continuously check if
it has reached its target, yielding to the caller to decide whether to keep
going. In contrast, it also provides a way to mark the process as timed out,
since announcing relies on waiting for events to come back in a timely manner.
2025-05-26 12:31:03 +02:00
Fintan Halpenny eec4dd4505 radicle: improve sync fetching
This patch changes separates the business logic of fetching from the process of
fetching itself. It does this through a sans-IO approach, where a `Fetcher`
provides the necessary state to help drive a fetch forward, without performing
any of the IO itself.

What the `Fetcher` cares about is:
- What nodes are going to be attempted to be fetched from
- In what order should they be attempted
- When should the fetching process be considered finished

The `Fetcher` is then used in `radicle-cli` to drive forward the `sync::fetch`
function, allowing it to only care about the IO.
2025-05-23 17:22:48 +01:00
Lorenz Leutgeb dc1ff882c5
cli/sync: Also print node addresses 2025-04-17 14:20:21 +02:00
Fintan Halpenny 84aaf9efd0
remote-helper: relax the quorum checks
The rules for checking the quorum of the remote helper, when pushing to the
canonical branch, can prevent the operator from even attempting to try converge
to a state of agreeance.

Instead, the checking of the quorum rules are relaxed. It is still the case that
if the peer is pushing a diverging commit while in a working state they are
warned and the push does not go through. However, there are two cases where it
is fine to force push a change:

1. When pushing a new tip, as a delegate, there is still a canonical tip and the
   new tip still converges with the history, i.e. it is equal to, behind, or
   ahead of another delegate tip.
2. If there is no quorum in the current state, for example there were multiple
   concurrent pushes, then the peer is free to continue to push to their default
   branch in attempt to converge with the other peers.

The example tests ensure that these cases are covered, while also preserving the
old behaviour.

Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
2024-07-03 15:14:58 +01:00