* Improve sandbox internal api
This improves the internal sandbox api for the executor implementations.
The main point is to hide the tls in the internal api and not having it
exposed to the outside.
This is especially needed for wasmtime 0.29.0
* Fmt
* Make it nicer
* add query types to generate_storage_alias
* adjust comment
* use ValueQuery explicitly for generate_storage_alias with generic value type
* bump impl_version
* adjust line width and add import
* more compilation and formatting fixes
* formatting
* Store the database in a role specific subdirectory
This is a cleaned up version of #8658 fixing #6880
polkadot companion: paritytech/polkadot#2923
* Disable prometheus in tests
* Also change p2p port
* Fix migration logic
* Use different identification file for rocks and parity db
Add tests for paritydb migration
* sp-utils => sc-utils
* cargo fmt
* These files are now in the client so should be licensed as GPL3
* Apply suggestions from code review
Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>
* doc: convert the adoc to md
* add ref to UncheckedExtrinsic
* Add references to the SS58 format
* Add details about the inspect command
* removing command that is no longer available
* reorder display so ss58 representations show up next to each other
* remove deprecated section
* Add doc about the password option
* fix fmt
* minor fixes
fix#6613
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
Co-authored-by: Squirrel <gilescope@gmail.com>
Co-authored-by: David <dvdplm@gmail.com>
* Migrate Aura pallet to BoundedVec
Implementing issue #8629
* Fixed aura tests after BoundedVec change
* Moved Vec to BoundedVec in authority-discovery
* Merging into the main branch
* Added MaxEncodedLen to crypto
Need this without full_crypto to be able to add generate_store_info
* Add generate_store_info for aura
* Adding changes to Slot to add MaxEncodedLen
* Adding generate_store_info to authority discovery
* fmt
* removing panics in runtime if vec size too large
* authority-discovery: Remove panics in runtime
Can happen if vec size is too large, so truncate the vec in that case
* Adding logging when I truncate Vecs
* Got the sign the other way around
* Reverting pallet_aura changes
This is already being addressed by PR #9371
* Change BoundedVec to WeakBoundedVec
More robust implementation following @thiolliere recommendation.
Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>
* add more errors for check attributes in npos elections solution type
* revert local env
* return Ok false if there are no attributes
* fmt
* Update primitives/npos-elections/solution-type/src/lib.rs
Co-authored-by: Squirrel <gilescope@gmail.com>
* Update primitives/npos-elections/solution-type/src/lib.rs
Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>
* Update primitives/npos-elections/solution-type/src/lib.rs
Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>
* Update primitives/npos-elections/solution-type/src/lib.rs
* improve span by giving extra attribute, nightly fmt
* fix test to test new error msg
Co-authored-by: Squirrel <gilescope@gmail.com>
Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>
The old implementation was listening for storage changes and every time
a block changed the `CODE` storage field, it checked if the runtime
version changed. It used the best block to compare against the latest
known runtime version. It could happen that you processed the storage
notification of block Y and checked the runtime version of block X (the
current best block). This is also what happened on parachains.
Parachains import blocks and set the new best block in a later step.
This means we imported the block that changed the code, got notified and
checked the runtime version of the current best block (which would still
be the parent of the block that changed the runtime). As the parent did
not changed the runtime, the runtime version also did not changed and we
never notified the subscribers.
The new implementation now switches to listen for best imported blocks.
Every time we import a new best block, we check its runtime version
against the latest known runtime version. As we also send a notification
when the parachains sets a block as new best block, we will trigger this
code path correctly. It moves some computation from checking if the key
was modified to getting the runtime version. As fetching the runtime
version is a rather common pattern, it should not make any big
difference performancewise.
Before we fetched the runtime code from the `TrieBackend` and this lead
to not using the storage cache. Thus, we recalculated the storage hash
for the runtime code on every call into the runtime and this killed the
performance on parachains block authoring. The solution is to fetch the
runtime code from the storage cache, to make sure we use the cached
storage cache.
Pierre Krieger