* http: Use assert_eq in tests for better debuggability
* http: Use matches! macro instead of if let ...
* http: Simplify some bits and pieces
* http: Don't answer immediately in HTTP test server
Sometimes it can happen that we receive the response immediately
when testing the HTTP api due to kernel scheduling. Because of it, we
add a marginal 10ms async-friendly delay to minimize the risk.
* http: Use the same async runtime when testing HTTP API/worker
* http: Return a future Delay only for non-zero Duration
This allows to short-circuit in the response_wait logic and only
send/not wait for response.
* client: Replace `unsafe_rpc_expose` with an `RpcMethods` enum
which can be either Default, Safe or Unsafe. The idea is to have the
following:
| | --rpc-external=false | --rpc-external=true |
|--------------------- |------------------- |----------------- |
| --rpc-methods=Default | | unsafe calls denied |
| --rpc-methods=Safe | unsafe calls denied | unsafe calls denied |
| --rpc-methods=Unsafe | | |
Since the previous `unsafe-rpc-expose` option was confusing.
* client: Only warn against exposing externally unsafe RPC method set
* Apply suggestions from code review
Co-Authored-By: Cecile Tonglet <cecile.tonglet@cecton.com>
* cli: Rephrase doc comment for rpc_methods config
* Improve debuggability of build_spec_works
...by printing to stderr the stderr of the command. This is normally
suppressed for succesful tests but not for failing ones - if that's the
case then it's useful to see the test failure reason inline rather than
having to execute the command separately ourselves.
* Rename RpcMethods::{Default => Auto} variant
* Update bin/node/cli/tests/build_spec_works.rs
Co-authored-by: Benjamin Kampmann <ben.kampmann@googlemail.com>
Co-authored-by: Cecile Tonglet <cecile.tonglet@cecton.com>
Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>
* service: Don't depend on tokio-executor
Seems to be a leftover dependency that's not used anymore.
* offchain: Upgrade hyper to 0.13, which uses tokio 0.2
* offchain: Adapt HTTP tests to Tokio 0.2
* network: Don't transitively include tokio 0.2 in WASM
1) We don't specifically depend on Tokio codec impls
2) Conflating features in Cargo means that enabling Tokio runtime
in the native environment will also do so in WASM, where it's
obviously not implemented and causes a compilation error.
* grafana-data-source: Pull hyper/tokio only in native environment
We don't use any explicit `#[lang = ...]` items anymore (`panic_fmt`
is replaced with now-stable `#[panic_implementation]`, OOM is handled
via `alloc_error_handler` directly etc.), so I thought it'd be good to
remove it for clarity to limit used nightly features.
Igor Matuszewski