Skip to content
  1. Apr 11, 2022
  3. Apr 09, 2022
    • dependabot[bot]'s avatar
      Bump proc-macro2 from 1.0.36 to 1.0.37 (#5265) · 3fef84a6
      dependabot[bot] authored 
      

Bumps [proc-macro2](https://github.com/dtolnay/proc-macro2) from 1.0.36 to 1.0.37.
- [Release notes](https://github.com/dtolnay/proc-macro2/releases)
- [Commits](https://github.com/dtolnay/proc-macro2/compare/1.0.36...1.0.37)

---
updated-dependencies:
- dependency-name: proc-macro2
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: default avatardependabot[bot] <[email protected]>

Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
      3fef84a6
    • Sergei Shulepov's avatar
      Fixes the dead lock when any of the channels get at capacity. (#5297) · b89dc00e
      Sergei Shulepov authored 
      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/a68d9be3/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/a68d9be3/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.
      b89dc00e
  5. Apr 08, 2022
  7. Apr 07, 2022
  9. Apr 06, 2022
  11. Apr 04, 2022
  13. Apr 03, 2022
  15. Apr 02, 2022
  17. Apr 01, 2022
  19. Mar 31, 2022
  21. Mar 30, 2022
  23. Mar 25, 2022
  25. Mar 24, 2022
    • Vsevolod Stakhov's avatar
      Try to fix out of view statements (#5177) · af94fc95
      Vsevolod Stakhov authored 
      This issue happens when some peer sends a good but already known Seconded statement and the statement-distribution code does not update the statements_received field in the peer_knowledge structure. Subsequently, a Valid statement causes out-of-view message that is incorrectly emitted and causes reputation lose.

This PR also introduces a concept of passing the specific pseudo-random generator to subsystems to make it easier to write deterministic tests. This functionality is not really necessary for the specific issue and unit test but it can be useful for other tests and subsystems.
      af94fc95
    • Koute's avatar
      Companion for Substrate#11107 (#5197) · b424e5e7
      Koute authored 
      

* Rename to BagError

* Additional parameter for 'revert' command

* Set aux revert param to None

* Align to changes in how the WASM executor is configured in `substrate`

* update lockfile for {"substrate"}

* update lockfile for {"substrate"}

* Update substrate

* Update substrate

Co-authored-by: default avatarKeith Yeung <[email protected]>
Co-authored-by: default avatarDavide Galassi <[email protected]>
Co-authored-by: default avatarShawn Tabrizi <[email protected]>
Co-authored-by: parity-processbot <>
      b424e5e7
  27. Mar 23, 2022
  29. Mar 22, 2022
  31. Mar 21, 2022
  33. Mar 18, 2022