* Add mmr_root() to pallet-mmr API to expose root from state
* use the right MmrApi primitives
* bridges: use correct mmr primitives
* rococo: beefy-mmr deposit mmr root digest
* fix lockfile
* update lockfile for {"substrate"}
Co-authored-by: parity-processbot <>
* beefy-gadget: allow custom runtime api provider
* beefy-gadget: use mock runtime api in tests
* pallet-mmr: expose mmr root from state through runtime API
* beefy-gadget: get mmr root from runtime state
* pallet-beefy-mmr: remove MmrRoot from header digests
* frame/mmr: move mmr primitives out of frame
* frame/mmr: completely move primitives out of frame
* address review comments
* beefy-mmr: bring back mmr root from header digest
* clippy fixes for rustc 1.60
* address review comments
* Handle relocation of `ParachainHost` in Polkadot
`ParachainHost` is no longer versioned and is in `runtime_api` module.
This is a companion for
https://github.com/paritytech/polkadot/pull/5048
* Update dependencies
* Move `trait ParachainHost` to a separate version independent module
`trait ParachainHost` is no longer part of a specific primitives
version. Instead there is a single trait for stable and staging api
versions. The trait contains stable AND staging methods. The latter are
explicitly marked as unstable.
* Fix `use` primitives
`polkadot_primitives::v2` becomes `polkadot_primitives::runtime_api`
* Staging API declaration and stubs
Introduces the concept for 'staging functions' in runtime API. These
functions are still in testing and they are meant to be used only
within test networks (Westend).
They coexist with the stable calls for technical reasons - maintaining
different runtime APIs for different networks is hard to implement.
Check the doc comments in source files for more details how the staging
API should be used.
* Add new staging method - get_session_disputes()
Add `staging_get_session_disputes` to `ParachainHost` as the first
method of the staging API.
* Hide vstaging runtime api implementations behind feature flag
* Fix test runtime
* fn staging_get_session_disputes() is renamed to fn staging_get_disputes()
* [Do not merge] add benchmarks to pipeline
* disable jobs for test
* Revert "[Do not merge] add benchmarks to pipeline"
This reverts commit af3cca09f2bbec7ab75e1e905314356ce4405a6f.
* add weights tag
* add stage
* empty before_script for benches
* run benchmarks on ci6
* disable cargo target dir
* disable pre-cache
* add CARGO_TARGET_DIR var to bench script
* debug
* debug
* fix script path
* divide build and benchmark into 2 jobs
* fix bench build
* small fix
* reduce benchmark output log
* add push github
* add push gh
* add after_script
* typo fix
* typo fix
* fix curl
* fix git config
* add title and body to pr
* final check that everything works
* final check that everything works
* return jobs back
* fix rules
* cancel changes benchmarks.sh
* Apply suggestions from code review
Co-authored-by: Denis Pisarev <denis.pisarev@parity.io>
* rename job
* change benches jobs to run on release-parachains-v*
* remove master refs
Co-authored-by: Denis Pisarev <denis.pisarev@parity.io>
* Finality notification: Optimize calculation of stale heads
While looking into some problem on Versi where a collator seemed to be stuck. I found out that it
was not stuck but there was a huge gap between last finalized and best block. This lead to a lot
leaves and it was basically trapped inside some loop of reading block headers from the db to find
the stale heads. While looking into this I found out that `leaves` already supports the feature to
give us the stale heads relative easily. However, the semantics change a little bit. Instead of
returning all stale heads of blocks that are not reachable anymore after finalizing a block, we
currently only return heads with a number lower than the finalized block. This should be no problem,
because these other leaves that are stale will be returned later when a block gets finalized which
number is bigger than the block number of these leaves.
While doing that, I also changed `tree_route` of the `FinalityNotification` to include the
`old_finalized`. Based on the comment I assumed that this was already part of it. However, if
wanted, I can revert this change.
* FMT
* Update client/service/src/client/client.rs
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
* Do not include the last finalized block
* Rename function
* FMT
* Fix tests
* Update figure
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
* Add new hardware and software metrics
* Move sysinfo tests into `mod tests`
* Correct a typo in a comment
* Remove unnecessary `nix` dependency
* Fix the version tests
* Add a `--disable-hardware-benchmarks` CLI argument
* Disable hardware benchmarks in the integration tests
* Remove unused import
* Fix benchmarks compilation
* Move code to a new `sc-sysinfo` crate
* Correct `impl_version` comment
* Move `--disable-hardware-benchmarks` to the chain-specific bin crate
* Move printing out of hardware bench results to `sc-sysinfo`
* Move hardware benchmarks to a separate messages; trigger them manually
* Rename some of the fields in the `HwBench` struct
* Revert changes to the telemetry crate; manually send hwbench messages
* Move sysinfo logs into the sysinfo crate
* Move the `TARGET_OS_*` constants into the sysinfo crate
* Minor cleanups
* Move the `HwBench` struct to the sysinfo crate
* Derive `Clone` for `HwBench`
* Fix broken telemetry connection notification stream
* Prevent the telemetry connection notifiers from leaking if they're disconnected
* Turn the telemetry notification failure log into a debug log
* Rename `--disable-hardware-benchmarks` to `--no-hardware-benchmarks`
* Prepare for rust stable 1.59
Besides preparing the UI tests this also adds a new script update-rust-stable.sh script for
simplifying the update of a rust stable version. This script will run all UI tests for the new
rust stable version and updating the expected output.
* Ensure we run the UI tests in CI
* use staging ci image
* More test updates
* Unignore test (#11097)
* empty commit for pipeline rerun
* empty commit for pipeline rerun
* Try to make clippy happy
* More clippy fixes
* FMT
* ci image production
Co-authored-by: alvicsam <alvicsam@gmail.com>
Co-authored-by: Alexander Samusev <41779041+alvicsam@users.noreply.github.com>
The PVF host is designed to avoid spawning tasks to minimize knowledge
of outer code. Using `async_std::task::spawn` (or Tokio's counterpart)
deemed unacceptable, `SpawnNamed` undesirable. Instead there is only one
task returned that is spawned by the candidate-validation subsystem.
The tasks from the sub-components are polled by that root task.
However, the way the tasks are bundled was incorrect. There was a giant
select that was polling those tasks. Particularly, that implies that as soon as
one of the arms of that select goes into await those sub-tasks stop
getting polled. This is a recipe for a deadlock which indeed happened
here.
Specifically, the deadlock happened during sending messages to the
execute queue by calling
[`send_execute`](https://github.com/paritytech/polkadot/blob/a68d9be35656dcd96e378fd9dd3d613af754d48a/node/core/pvf/src/host.rs#L601).
When the channel to the queue reaches the capacity, the control flow is
suspended until the queue handles those messages. Since this code is
essentially reached from [one of the select
arms](https://github.com/paritytech/polkadot/blob/a68d9be35656dcd96e378fd9dd3d613af754d48a/node/core/pvf/src/host.rs#L371),
the queue won't be given the control and thus no further progress can be
made.
This problem is solved by bundling the tasks one level higher instead,
by `selecting` over those long-running tasks.
We also stop treating returning from those long-running tasks as error
conditions, since that can happen during legit shutdown.
Oliver Tale-Yazdi