Previously, every inbound or outbound upgrade generated a log at `debug` level, without information about the upgrade.
This commit changes it such that successful upgrades are logged at `trace` level (due to ubiquitous use of OneShot handlers) and that the negotiated protocol name is included in the message.
The task for a pending connection only ever sends one event into this channel: Either a success or a failure. Cloning a sender adds one slot to the capacity of the channel. Hence, we can start this capacity at 0 and have the `cloning` of the `Sender` take care of properly increasing the capacity.
As I do frequently, I corrected for the latest clippy warnings. This will make sure the CI won't complain in the future. We could automate this btw and maybe run the nightly version of clippy.
This patch deprecates 3 out of 4 functions on `PollParameters`:
- `local_peer_id`
- `listened_addresses`
- `external_addresses`
The addresses can be obtained by inspecting the `FromSwarm` event. To make this easier, we introduce two utility structs in `libp2p-swarm`:
- `ExternalAddresses`
- `ListenAddresses`
A node's `PeerId` is always known to the caller, thus we can require them to pass it in.
Related: #3124.
Currently, we create a new cache for each workflow run for each crate. That ends up blowing the maximum allowed cache size of 10GB and GitHub deletes the least-recently used cache again. Effectively, this means we don't have any caching.
This patch introduces a cache factory workflow that only runs on master and always _saves_ a new cache. The CI workflow run for pull-requests on the other hand only restore these caches but don't save them.
Currently, a user can push code after it has been approved and the send-it label applied. We only want to merge code that we actually looked at. Use mergify to dismiss approvals in such circumstances.
`cargo semver-checks` is still missing features in regards to properly detecting renamed exports. To make our CI pass again, we remove the renamed export, replace it with type-aliases and deprecate them to point users types exported under a module which now follows the conventions set in #2217.
Add support for QUIC draft-29 / the `quic` codepoint. This enables both dialing and listening on `quic` addresses.
The motivation for adding support is to allow users to connect to old go-libp2p nodes that don't support the `quic-v1` codepoint.
**Per default support is disabled.**
`libp2p-swarm-derive` released a breaking change (https://github.com/libp2p/rust-libp2p/pull/3011)
as a patch release `v0.30.2`.
This patch:
1. Prepares a new minor release of `libp2p-swarm-derive`.
2. Prepares a patch release for `libp2p-swarm` to use the minor release of `libp2p-swarm-derive`.
As a follow up we can yank the `libp2p-swarm-derive` `v0.30.2` release. In addition we might want to
release `libp2p-swarm-derive` `v0.30.3` containing all patches but https://github.com/libp2p/rust-libp2p/pull/3011.
- Only send `STOP_SENDING` on a stream when dropping it if the remote did not finish the stream yet.
- Only call `quinn_proto::SendStream::finish` once. (A second call to it will always fail. Though I don't think this was the issue in #3144.)
- Add tests for reading and writing to streams after the remote dropped. Also adds a smoke test for backpressure.
Fixes#3144.
Previously, we would erroneously always go into the `WaitingUser` (now called `WaitingBehaviour`) state after receiving a message on an inbound stream. However, the `AddProvider` message does not warrant a "response" from the behaviour. Thus, any incoming `AddProvider` message would result in a stale substream that would eventually be dropped as soon as more than 32 inbound streams have been opened.
With this patch, we inline the message handling into the upper match block and perform the correct state transition upon each message. For `AddProvider`, we go back into `WaitingMessage` because the spec mandates that we need to be ready to receive more messages on an inbound stream.
Fixes#3048.
In case support for e.g. RSA keys is disabled at compile-time, we will now print a better error message. For example:
> Failed to dial Some(PeerId("QmcZf59bWwK5XFi76CZX8cbJ4BhTzzA3gU1ZjYZcYW3dwt")): Failed to negotiate transport protocol(s): [(/dnsaddr/bootstrap.libp2p.io/p2p/QmcZf59bWwK5XFi76CZX8cbJ4BhTzzA3gU1ZjYZcYW3dwt): : Handshake failed: Handshake failed: Invalid public key: Key decoding error: RSA keys are unsupported)]
Fixes#2971.
This PR tweaks the installation of `cargo-semver-checks` to make it use the `--locked` flag.
Installing binaries with their locked dependency versions makes it less likely that you might run into issues caused by bugs in dependency libraries, since your installed dependency versions match the versions used in the binary's own test environment.
This is a recommendation that applies to most Rust binary tools. For example, here's cargo-nextest recommending the same: https://nexte.st/book/installing-from-source.html#installing-from-cratesio
We refactor our continuous integration workflow with the following goals in mind:
- Run as few jobs as possible
- Have the jobs finish as fast as possible
- Have the jobs redo as little work as possible
There are only so many jobs that GitHub Actions will run in parallel.
Thus, it makes sense to not create massive matrices but instead group
things together meaningfully.
The new `test` job will:
- Run once for each crate
- Ensure that the crate compiles on its specified MSRV
- Ensure that the tests pass
- Ensure that there are no semver violations
This is an improvement to before because we are running all of these
in parallel which speeds up execution and highlights more errors at
once. Previously, tests run later in the pipeline would not get run
at all until you make sure the "first" one passes.
We also previously did not verify the MSRV of each crate, making the
setting in the `Cargo.toml` rather pointless.
The new `cross` job supersedes the existing `wasm` job.
This is an improvement because we now also compile the crate for
windows and MacOS. Something that wasn't checked before.
We assume that checking MSRV and the tests under Linux is good enough.
Hence, this job only checks for compile-errors.
The new `feature_matrix` ensures we compile correctly with certain feature combinations.
`libp2p` exposes a fair few feature-flags. Some of the combinations
are worth checking independently. For the moment, this concerns only
the executor related transports together with the executor flags but
this list can easily be extended.
The new `clippy` job runs for `stable` and `beta` rust.
Clippy gets continuously extended with new lints. Up until now, we would only
learn about those as soon as a new version of Rust is released and CI would
run the new lints. This leads to unrelated failures in CI. Running clippy on with `beta`
Rust gives us a heads-up of 6 weeks before these lints land on stable.
Fixes#2951.
Previously, we would always run `IfWatcher`, even if we were only listening on a specific interface. This patch fixes this behaviour and aligns it with how `libp2p-quic` operates.
Previously, we had one callback for each kind of message that a `ConnectionHandler` would receive from either its `NetworkBehaviour` or the connection itself.
With this patch, we combine these functions, resulting in two callbacks:
- `on_behaviour_event`
- `on_connection_event`
Resolves#3080.
Currently, `libp2p-mdns` fails to compile unless we enable the `tokio` runtime feature flag. This is caused by missing `cfg` statements upstream. See https://github.com/bluejekyll/trust-dns/issues/1830.
Until this is fixed upstream, we temporarily enable the `tokio-runtime` feature of `trust-dns-proto`.
Previously, we would only track the metrics like the number of open connections. With this patch, we extend these metrics with a `protocols` label that contains a "protocol stack". A protocol stack is a multi-address with all variable parts removed. For example, `/ip4/127.0.0.1/tcp/1234` turns into `/ip4/tcp`.
Resolves https://github.com/libp2p/rust-libp2p/issues/2758.
