Currently, `Limit` is supplied to many of relay client events, however there is no way to access the fields. This PR adds functions to allow access to the data from those fields.
Pull-Request: #4162.
Since https://github.com/libp2p/rust-libp2p/pull/3973, gossipsub now fully supports wasm targets. It functions properly when added as a dependency on its own. However, when trying to use it under libp2p by activating a feature, it's not possible and the compiler will raise an error like `unresolved import libp2p::gossipsub`. This pull request enables the use of gossipsub for wasm targets when it's activated as a feature of the libp2p dependency.
Pull-Request: #4217.
We also need to prepend the `clippy::allow` with an `unknown_lints` lint because clippy 1.71 does not (yet) know about this new lint.
Pull-Request: #4219.
We receive a lot of PRs from dependabot for version updates to our lockfile and Cargo.toml. Whilst it is nice that those are explicit, they require quite some work from maintainers. Often, these PRs only get queued to be merged when a maintainer is next active on a repository which is also likely at a time they want to merge other PRs.
We don't want to automatically merge all updates that are coming in because they might be breaking changes for us if they are exposed in our public API. We solve this by only merging updates that are in a semver-compatible range:
- For major >= 1 updates, only approve them if they have the same major version.
- For major == 0 updates, only approve them if they have the same minor version.
We also add a rule to automatically queue PRs from dependabot with an approval. This avoids us having to approve AND apply the `send-it` label.
Resolves#4186.
Pull-Request: #4210.
I'm not able to build this container on my machine arm64 linux because the builder is missing the `wasm-opt` binary. I'm not sure why CI manages to do so. I'm guessing the x86 image is slightly different and may include `wasm-opt`.
This makes a change to that dockerfile to explicitly install `wasm-opt`.
Here's the previous error:
```
// ...
#0 36.90 Finished release [optimized] target(s) in 35.97s
#0 36.91 Installing /root/.cache/.wasm-pack/.wasm-bindgen-cargo-install-0.2.87/bin/wasm-bindgen
#0 36.91 Installing /root/.cache/.wasm-pack/.wasm-bindgen-cargo-install-0.2.87/bin/wasm-bindgen-test-runner
#0 36.91 Installing /root/.cache/.wasm-pack/.wasm-bindgen-cargo-install-0.2.87/bin/wasm2es6js
#0 36.91 Installed package `wasm-bindgen-cli v0.2.87` (executables `wasm-bindgen`, `wasm-bindgen-test-runner`, `wasm2es6js`)
#0 37.06 warning: be sure to add `/root/.cache/.wasm-pack/.wasm-bindgen-cargo-install-0.2.87/bin` to your PATH to be able to run the installed binaries
#0 37.22 Error: no prebuilt wasm-opt binaries are available for this platform: Unrecognized target!
#0 37.22 To disable `wasm-opt`, add `wasm-opt = false` to your package metadata in your `Cargo.toml`.
#0 37.22 Caused by: no prebuilt wasm-opt binaries are available for this platform: Unrecognized target!
#0 37.22 To disable `wasm-opt`, add `wasm-opt = false` to your package metadata in your `Cargo.toml`.
------
ERROR: failed to solve: executor failed running [/bin/sh -c wasm-pack build --target web interop-tests]: exit code: 1
```
Another solution would be to diable wasm-opt as mentioned in the error message as well.
Pull-Request: #4192.
With the move to running our CI on self-hosted runners, this job tends to always be the slowest one. We move it to a bigger runner such that it finishes closer to all the other jobs.
Pull-Request: #3861.
- Fixes typo in `<OrTransport as Transport>::listen_on` using the word "dial" instead of "listen_on".
- Adds logging to `<OrTransport as Transport>::dial`.
Follow-up to https://github.com/libp2p/rust-libp2p/pull/4133
Pull-Request: #4164.
Currently, when trying addresses in `listen_on` via `OrTransport`, there are no logs to facilitate debugging. This PR corrects that by providing adequate logs via `std::any::type_name` method.
Resolves#4072.
Pull-Request: #4133.
The current implementation in Kademlia relies on an external address to determine if it should be in client or server mode. However there are instances where a node, which may know an external address, wishes to remain in client mode and switch to server mode at a later point.
This PR introduces `Kademlia::set_mode`, which accepts an `Option<Mode>` that would allow one to set `Mode::Client` for client mode, `Mode::Server` for server mode, or `None` to determine if we should operate as a client or server based on our external addresses.
Resolves#4074.
Pull-Request: #4132.
