Remove the specific fee amount checks in integration tests, since it
changes every time weights are regenerated.

#### Description
During 2s block investigation it turned out that
[ForkAwareTxPool::register_listeners](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/client/transaction-pool/src/fork_aware_txpool/fork_aware_txpool.rs#L1036)
call takes significant amount of time.
```
register_listeners: at HashAndNumber { number: 12, hash: 0xe9a1...0b1d2 } took 200.041933ms
register_listeners: at HashAndNumber { number: 13, hash: 0x5eb8...a87c6 } took 264.487414ms
register_listeners: at HashAndNumber { number: 14, hash: 0x30cb...2e6ec } took 340.525566ms
register_listeners: at HashAndNumber { number: 15, hash: 0x0450...4f05c } took 405.686659ms
register_listeners: at HashAndNumber { number: 16, hash: 0xfa6f...16c20 } took 477.977836ms
register_listeners: at HashAndNumber { number: 17, hash: 0x5474...5d0c1 } took 483.046029ms
register_listeners: at HashAndNumber { number: 18, hash: 0x3ca5...37b78 } took 482.715468ms
register_listeners: at HashAndNumber { number: 19, hash: 0xbfcc...df254 } took 484.206999ms
register_listeners: at HashAndNumber { number: 20, hash: 0xd748...7f027 } took 414.635236ms
register_listeners: at HashAndNumber { number: 21, hash: 0x2baa...f66b5 } took 418.015897ms
register_listeners: at HashAndNumber { number: 22, hash: 0x5f1d...282b5 } took 423.342397ms
register_listeners: at HashAndNumber { number: 23, hash: 0x7a18...f2d03 } took 472.742939ms
register_listeners: at HashAndNumber { number: 24, hash: 0xc381...3fd07 } took 489.625557ms
```

This PR implements the idea outlined in #7071. Instead of having a
separate listener for every transaction in each view, we now use a
single stream of aggregated events per view, with each stream providing
events for all transactions in that view. Each event is represented as a
tuple: (transaction-hash, transaction-status). This significantly reduce
the time required for `maintain`.

#### Review Notes
- single aggregated stream, provided by the individual view delivers
events in form of `(transaction-hash, transaction-status)`,
- `MultiViewListener` now has a task. This task is responsible for:
- polling the stream map (which consists of individual view's aggregated
streams) and the `controller_receiver` which provides side-channel
[commands](https://github.com/paritytech/polkadot-sdk/blob/2b18e080

/substrate/client/transaction-pool/src/fork_aware_txpool/multi_view_listener.rs#L68-L95)
(like `AddView` or `FinalizeTransaction`) sent from the _transaction
pool_.
- dispatching individual transaction statuses and control commands into
the external (created via API, e.g. over RPC) listeners of individual
transactions,
- external listener is responsible for status handling _logic_ (e.g.
deduplication of events, or ignoring some of them) and triggering
statuses to external world (_this was not changed_).
- level of debug messages was adjusted (per-tx messages shall be
_trace_),

Closes #7071

---------

Co-authored-by: Sebastian Kunert <skunert49@gmail.com>

Related to https://github.com/paritytech/polkadot-sdk/issues/7400 and
https://github.com/paritytech/polkadot-sdk/pull/7417

We need this in order to be able to update `parity-scale-codec` to the
latest version after it's released. That's because `parity-scale-codec`
added support for checking for duplicate indexes at compile time.

Fixes https://github.com/paritytech/polkadot-sdk/issues/7400

# Description

Another small fix for sync-templates. We're copying the `polkadot-sdk`'s
`parachain-template` files (including the `parachain-template-docs`'s
Cargo.toml) to the directory where we're creating the workspace with all
`parachain-template` members crates, and workspace's toml. The error is
that in this directory for the workspace we first create the workspace's
Cargo.toml, and then copy the files of the `polkadot-sdk`'s
`parachain-template`, including the `Cargo.toml` of the
`parachain-template-docs` crate, which overwrites the workspace
Cargo.toml. In the end we delete the `Cargo.toml` (which we assume it is
of the `parachain-template-docs` crate), forgetting that previously
there should've been a workspace Cargo.toml, which should still be kept
and committed to the template's repository.

The error happens here:
https://github.com/paritytech/polkadot-sdk/actions/runs/13111697690/job/36577834127

## Integration

N/A

## Review Notes

Once again, merging this into master requires re-running sync templates
based on latest version on master. Hopefully this will be the last issue
related to the workflow itself.

---------

Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>

# Description

Aligned `polkadot-omni-node` & `polkadot-parachain` versions. There is
one `NODE_VERSION` constant, in `polkadot-omni-node-lib`, used by both
binaries.

Closes #7276 .

## Integration

Node operators will know what versions of `polkadot-omni-node` &
`polkadot-parachain` they use since their versions will be kept in sync
with the stable release `polkadot` SemVer version.

## Review Notes

TODO:
- [x] update NODE_VERSION of `polkadot-omni-node-lib` when running
branch off workflow

---------

Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>

This PR changes the behavior of `instantiate` when the resulting
contract address already exists (because the caller tried to instantiate
the same contract with the same salt multiple times): Instead of
trapping the caller, return an error code.

Solidity allows `catch`ing this, which doesn't work if we are trapping
the caller. For example, the change makes the following snippet work:

```Solidity
try new Foo{salt: hex"00"}() returns (Foo) {
    // Instantiation was successful (contract address was free and constructor did not revert)
} catch {
    // This branch is expected to be taken if the instantiation failed because of a duplicate salt
}
```

`revive` PR: https://github.com/paritytech/revive/pull/188

---------

Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

address failed CI after full regeneration

Example https://github.com/paritytech/polkadot-sdk/pull/7406
Failed CI
https://github.com/paritytech/polkadot-sdk/actions/runs/13070646240

Monkey-patched weights which have been overridden by automation

![image](https://github.com/user-attachments/assets/ecf69173-f4dd-4113-a319-4f29d779ecae)

Part of https://github.com/paritytech/polkadot-sdk/issues/5079.

Removes all usage of the static async backing params, replacing them
with dynamically computed equivalent values (based on the claim queue
and scheduling lookahead).

Adds a new runtime API for querying the scheduling lookahead value. If
not present, falls back to 3 (the default value that is backwards
compatible with values we have on production networks for
allowed_ancestry_len)

Also resolves most of
https://github.com/paritytech/polkadot-sdk/issues/4447, removing code
that handles async backing not yet being enabled.
While doing this, I removed the support for collation protocol version 1
on collators, as it only worked for leaves not supporting async backing
(which are none).
I also unhooked the legacy v1 statement-distribution (for the same
reason as above). That subsystem is basically dead code now, so I had to
remove some of its tests as they would no longer pass (since the
subsystem no longer sen...

# Description

There is a small error (which slipped through reviews) in matrix
strategy expansion which results in errors like this:
https://github.com/paritytech/polkadot-sdk/actions/runs/13079943579/job/36501002368.

## Integration

N/A

## Review Notes

Need to fix this in master and then rerun it manually against
`stable2412-1`.

Signed-off-by: Iulian Barbu <iulian.barbu@parity.io>

This PR backports regular version bumps and prdoc reorganization from
stable release branch back to master

This should fix the error log related to PoV pre-dispatch weight being
lower than post-dispatch for `ParasInherent`:
```
ERROR tokio-runtime-worker runtime::frame-support: Post dispatch weight is greater than pre dispatch weight. Pre dispatch weight may underestimating the actual weight. Greater post dispatch weight components are ignored.
                                        Pre dispatch weight: Weight { ref_time: 47793353978, proof_size: 1019 },
                                        Post dispatch weight: Weight { ref_time: 5030321719, proof_size: 135395 }
```

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

malus-collator: implement malicious collator submitting same collation to all backing groups (#6924)

## Issues
- [[#5049] Elastic scaling: zombienet
tests](https://github.com/paritytech/polkadot-sdk/issues/5049)
- [[#4526] Add zombienet tests for malicious
collators](https://github.com/paritytech/polkadot-sdk/issues/4526)

## Description
Modified the undying collator to include a malus mode, in which it
submits the same collation to all assigned backing groups.

## TODO
* [X] Implement malicious collator that submits the same collation to
all backing groups;
* [X] Avoid the core index check in the collation generation subsystem:
https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/node/collation-generation/src/lib.rs#L552-L553;
* [X] Resolve the mismatch between the descriptor and the commitments
core index: https://github.com/paritytech/polkadot-sdk/pull/7104
* [X] Implement `duplicate_collations` test with zombienet-sdk;
* [X] Add PRdoc.

This PR modifies the fatxpool to use tracing instead of log for logging.

closes #5490

Polkadot address: 12GyGD3QhT4i2JJpNzvMf96sxxBLWymz4RdGCxRH5Rj5agKW

---------

Co-authored-by: Michal Kucharczyk <1728078+michalkucharczyk@users.noreply.github.com>

- added 3 links for subweight comparison - now, ~1 month ago release, ~3
month ago release tag
- added `--3way --ours` flags for `git apply` to resolve potential
conflict
- stick to the weekly branch from the start until the end, to prevent
race condition with conflicts

# Description

Close #7122.

This PR replaces the unmaintained `derivative` dependency with
`derive-where`.

## Integration

This PR doesn't change the public interfaces.

## Review Notes

The `derivative` crate, previously used to derive basic traits for
structs with generics or enums, is no longer actively maintained. It has
been replaced with the `derive-where` crate, which offers a more
straightforward syntax while providing the same features as
`derivative`.

---------

Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>

# Description

Currently benchmarks and tests on pallet_balances would fail when the
feature insecure_zero_ed is enabled. This PR allows to run such
benchmark and tests keeping into account the fact that accounts would
not be deleted when their balance goes below a threshold.

## Integration

*In depth notes about how this PR should be integrated by downstream
projects. This part is mandatory, and should be
reviewed by reviewers, if the PR does NOT have the `R0-Silent` label. In
case of a `R0-Silent`, it can be ignored.*

## Review Notes

*In depth notes about the **implementation** details of your PR. This
should be the main guide for reviewers to
understand your approach and effectively review it. If too long, use

[`<details>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details)*.

*Imagine that someone who is depending on the old code wants to
integrate your new code and the only information that
they get is this section. It helps to include example usage and default
value here, with a `diff` code-block to show
possibly integration.*

*Include your leftover TODOs, if any, here.*

# Checklist

* [x] My PR includes a detailed description as outlined in the
"Description" and its two subsections above.
* [x] My PR follows the [labeling requirements](

https://github.com/paritytech/polkadot-sdk/blob/master/docs/contributor/CONTRIBUTING.md#Process
) of this project (at minimum one label for `T` required)
* External contributors: ask maintainers to put the right label on your
PR.
* [x] I have made corresponding changes to the documentation (if
applicable)
* [x] I have added tests that prove my fix is effective or that my
feature works (if applicable)

You can remove the "Checklist" section once all have been checked. Thank
you for your contribution!

✄
-----------------------------------------------------------------------------

---------

Co-authored-by: Rodrigo Quelhas <rodrigo_quelhas@outlook.pt>

Related to:
https://github.com/paritytech/polkadot-sdk/issues/7295#issuecomment-2607211278

---------

Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Adrian Catangiu <adrian@parity.io>

This PR contains small fixes and backwards compatibility issues
identified during work on the larger PR:
https://github.com/paritytech/polkadot-sdk/issues/6906.

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

# Description

Migrating cumulus-pallet-session-benchmarking to the new benchmarking
syntax v2.
This is a part of #6202

---------

Co-authored-by: seemantaggarwal <32275622+seemantaggarwal@users.noreply.github.com>
Co-authored-by: Bastian Köcher <git@kchr.de>

This PR implements the block author API method. Runtimes ought to
implement it such that it corresponds to the `coinbase` EVM opcode.

---------

Signed-off-by: xermicus <cyrill@parity.io>
Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Co-authored-by: command-bot <>
Co-authored-by: Alexander Theißen <alex.theissen@me.com>
Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

This PR modifies `named_reserve()` in frame-balances to use checked math
instead of defensive saturating math.

The use of saturating math relies on the assumption that the sum of the
values will always fit in `u128::MAX`. However, there is nothing
preventing the implementing pallet from passing a larger value which
overflows. This can happen if the implementing pallet does not validate
user input and instead relies on `named_reserve()` to return an error
(this saves an additional read)

This is not a security concern, as the method will subsequently return
an error thanks to `<Self as ReservableCurrency<_>>::reserve(who,
value)?;`. However, the `defensive_saturating_add` will panic in
`--all-features`, creating false positive crashes in fuzzing operations.

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

- remove old bench from cmd.py and left alias for backward compatibility
- reverted the frame-wight-template as the problem was that it umbrella
template wasn't picked correctly in the old benchmarks, in
frame-omni-bench it correctly identifies the dependencies and uses
correct template

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

cc https://github.com/paritytech/ci_cd/issues/1101

Instead of using libp2p-provided external address candidates,
susceptible to address translation issues, use litep2p-backend approach
based on confirming addresses observed by multiple peers as external.

Fixes https://github.com/paritytech/polkadot-sdk/issues/7207.

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

The old error message was often confusing, because the real reason for
the error will be printed during inherent execution.

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Closes #216.

This PR allows pallets to define a `view_functions` impl like so:

```rust
#[pallet::view_functions]
impl<T: Config> Pallet<T>
where
	T::AccountId: From<SomeType1> + SomeAssociation1,
{
	/// Query value no args.
	pub fn get_value() -> Option<u32> {
		SomeValue::<T>::get()
	}

	/// Query value with args.
	pub fn get_value_with_arg(key: u32) -> Option<u32> {
		SomeMap::<T>::get(key)
	}
}
```
### `QueryId`

Each view function is uniquely identified by a `QueryId`, which for this
implementation is generated by:

```twox_128(pallet_name) ++ twox_128("fn_name(fnarg_types) -> return_ty")```

The prefix `twox_128(pallet_name)` is the same as the storage prefix for pallets and take into account multiple instances of the same pallet.

The suffix is generated from the fn type signature so is guaranteed to be unique for that pallet impl. For one of the view fns in the example above it would be `twox_128("get_value_with_arg(u32) -> Option<u32>")`. It is a known limitation that only the type names themselves are taken into account: in the case of type aliases the signature may have the same underlying types but a different id; for generics the concrete types may be different but the signatures will remain the same.

The existing Runtime `Call` dispatchables are addressed by their concatenated indices `pallet_index ++ call_index`, and the dispatching is handled by the SCALE decoding of the `RuntimeCallEnum::PalletVariant(PalletCallEnum::dispatchable_variant(payload))`. For `view_functions` the runtime/pallet generated enum structure is replaced by implementing the `DispatchQuery` trait on the outer (runtime) scope, dispatching to a pallet based on the id prefix, and the inner (pallet) scope dispatching to the specific function based on the id suffix.

Future implementations could also modify/extend this scheme and routing to pallet agnostic queries.

### Executing externally

These view functions can be executed externally via the system runtime api:

```rust
pub trait ViewFunctionsApi<QueryId, Query, QueryResult, Error> where
	QueryId: codec::Codec,
	Query: codec::Codec,
	QueryResult: codec::Codec,
	Error: codec::Codec,
{
	/// Execute a view function query.
fn execute_query(query_id: QueryId, query: Query) -> Result<QueryResult,
Error>;
}
```
### `XCQ`
Currently there is work going on by @xlc to implement [`XCQ`](https://github.com/open-web3-stack/XCQ/) which may eventually supersede this work.

It may be that we still need the fixed function local query dispatching in addition to XCQ, in the same way that we have chain specific runtime dispatchables and XCM.

I have kept this in mind and the high level query API is agnostic to the underlying query dispatch and execution. I am just providing the implementation for the `view_function` definition.

### Metadata
Currently I am utilizing the `custom` section of the frame metadata, to avoid modifying the official metadata format until this is standardized.

### vs `runtime_api`
There are similarities with `runtime_apis`, some differences being:
- queries can be defined directly on pallets, so no need for boilerplate declarations and implementations
- no versioning, the `QueryId` will change if the signature changes. 
- possibility for queries to be executed from smart contracts (see below)

### Calling from contracts
Future work would be to add `weight` annotations to the view function queries, and a host function to `pallet_contracts` to allow executing these queries from contracts.

### TODO

- [x] Consistent naming (view functions pallet impl, queries, high level api?)
- [ ] End to end tests via `runtime_api`
- [ ] UI tests
- [x] Mertadata tests
- [ ] Docs

---------

Co-authored-by: kianenigma <kian@parity.io>
Co-authored-by: James Wilson <james@jsdw.me>
Co-authored-by: Giuseppe Re <giuseppe.re@parity.io>
Co-authored-by: Guillaume Thiolliere <guillaume.thiolliere@parity.io>

This PR changes how we call runtime API methods with more than 6
arguments: They are no longer spilled to the stack but packed into
registers instead. Pointers are 32 bit wide so we can pack two of them
into a single 64 bit register. Since we mostly pass pointers, this
technique effectively increases the number of arguments we can pass
using the available registers.

To make this work for `instantiate` too we now pass the code hash and
the call data in the same buffer, akin to how the `create` family
opcodes work in the EVM. The code hash is fixed in size, implying the
start of the constructor call data.

---------

Signed-off-by: xermicus <cyrill@parity.io>
Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com>
Co-authored-by: command-bot <>
Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Alexander Theißen <alex.theissen@me.com>

On top of https://github.com/paritytech/polkadot-sdk/pull/6757

Fixes https://github.com/paritytech/polkadot-sdk/issues/6858 by bumping
the `PARENT_SEARCH_DEPTH` constant to a larger value (30) and adds a
zombienet-sdk test that exercises the 12-core scenario.

This is a node-side limit that restricts the number of allowed pending
availability candidates when choosing the parent parablock during
authoring.
This limit is rather redundant, as the parachain runtime already
restricts the unincluded segment length to the configured value in the
[FixedVelocityConsensusHook](https://github.com/paritytech/polkadot-sdk/blob/88d900af

/cumulus/pallets/aura-ext/src/consensus_hook.rs#L35)
(which ideally should be equal to this `PARENT_SEARCH_DEPTH`).

For 12 cores, a value of 24 should be enough, but I bumped it to 30 to
have some extra buffer.

There are two other potential ways of fixing this:
- remove this constant altogether, as the parachain runtime already
makes those guarantees. Chose not to do this, as it can't hurt to have
an extra safeguard
- set this value to be equal to the uninlcuded segment size. This value
however is not exposed to the node-side and would require a new runtime
API, which seems overkill for a redundant check.

---------

Co-authored-by: Javier Viola <javier@parity.io>

Resolves (partially):
https://github.com/paritytech/polkadot-sdk/issues/7148 (see _Problem 1 -
`ShouldExecute` tuple implementation and `Deny` filter tuple_)

This PR changes the behavior of `DenyThenTry` from the pattern
`DenyIfAllMatch` to `DenyIfAnyMatch` for the tuple.

I would expect the latter is the right behavior so make the fix in
place, but we can also add a dedicated Impl with the legacy one
untouched.

## TODO
- [x] add unit-test for `DenyReserveTransferToRelayChain`
- [x] add test and investigate/check `DenyThenTry` as discussed
[here](https://github.com/paritytech/polkadot-sdk/pull/6838#discussion_r1914553990)
and update documentation if needed

---------

Co-authored-by: Branislav Kontur <bkontur@gmail.com>
Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com>
Co-authored-by: command-bot <>
Co-authored-by: Clara van Staden <claravanstaden64@gmail.com>
Co-authored-by: Adrian Catangiu <adrian@parity.io>

#Description
Migrated polkadot-runtime-parachains slots benchmarking to the new
benchmarking syntax v2.
This is part of #6202

---------

Co-authored-by: Giuseppe Re <giuseppe.re@parity.io>
Co-authored-by: seemantaggarwal <32275622+seemantaggarwal@users.noreply.github.com>
Co-authored-by: Bastian Köcher <git@kchr.de>

# Description

This PR adds development chain specs for the minimal and parachain
templates.
[#6334](https://github.com/paritytech/polkadot-sdk/issues/6334)


## Integration

This PR adds development chain specs for the minimal and para chain
template runtimes, ensuring synchronization with runtime code. It
updates zombienet-omni-node.toml, zombinet.toml files to include valid
chain spec paths, simplifying configuration for zombienet in the
parachain and minimal template.

## Review Notes

1. Overview of Changes:
- Added development chain specs for use in the minimal and parachain
template.
- Updated zombienet-omni-node.toml and zombinet.toml files in the
minimal and parachain templates to include paths to the new dev chain
specs.

2. Integration Guidance:
**NB: Follow the templates' READMEs from the polkadot-SDK master branch.
Please build the binaries and runtimes based on the polkadot-SDK master
branch.**
- Ensure you have set up your runtimes `parachain-template-runtime` and
`minimal-template-runtime`
- Ensure you have installed the nodes required ie
`parachain-template-node` and `minimal-template-node`
- Set up [Zombinet](https://paritytech.github.io/zombienet/intro.html)
- For running the parachains, you will need to install the polkadot
`cargo install --path polkadot` remember from the polkadot-SDK master
branch.
- Inside the template folders minimal or parachain, run the command to
start with `Zombienet with Omni Node`, `Zombienet with
minimal-template-node` or `Zombienet with parachain-template-node`

*Include your leftover TODOs, if any, here.*
* [ ] Test the syncing of chain specs with runtime's code.

---------

Signed-off-by: EleisonC <ckalule7@gmail.com>
Co-authored-by: Iulian Barbu <14218860+iulianbarbu@users.noreply.github.com>
Co-authored-by: Alexander Samusev <41779041+alvicsam@users.noreply.github.com>

closes #5978

---------

Co-authored-by: command-bot <>
Co-authored-by: Michal Kucharczyk <1728078+michalkucharczyk@users.noreply.github.com>

Revert https://github.com/paritytech/polkadot-sdk/pull/7011 and replace
it with a backward-compatible solution suitable for backporting to a
release branch.

### Review notes
It's easier to review this PR per commit: the first commit is just a
revert, so it's enough to review only the second one, which is almost a
one-liner.

---------

Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Part of: https://github.com/paritytech/polkadot-sdk/issues/6906

Improve debugging by using `#[track_caller]` in system `assert_last_event` and `assert_has_event` (#7142)

Without track caller the error message of the assert points to the
`assert_last_event` function, which is not useful.
```
thread 'tests::set_metadata_works' panicked at /home/gui/Developpement/polkadot-sdk/substrate/frame/system/src/lib.rs:2034:9:
assertion `left == right` failed: expected event RuntimeEvent::Referenda(Event::MetadataSet { index: 0, hash: 0xbb30a42c1e62f0afda5f0a4e8a562f7a13a24cea00ee81917b86b89e801314aa }) is not equal to the last event RuntimeEvent::Referenda(Event::MetadataSet { index: 1, hash: 0xbb30a42c1e62f0afda5f0a4e8a562f7a13a24cea00ee81917b86b89e801314aa })
  left: RuntimeEvent::Referenda(Event::MetadataSet { index: 1, hash: 0xbb30a42c1e62f0afda5f0a4e8a562f7a13a24cea00ee81917b86b89e801314aa })
 right: RuntimeEvent::Referenda(Event::MetadataSet { index: 0, hash: 0xbb30a42c1e62f0afda5f0a4e8a562f7a13a24cea00ee81917b86b89e801314aa })
```

With the track caller the error message points to the caller, showing
the source of the error:
```
thread 'tests::set_metadata_works' panicked at substrate/frame/referenda/src/tests.rs:639:9:
assertion `left == right` failed: expected event RuntimeEvent::Referenda(Event::MetadataSet { index: 0, hash: 0xbb30a42c1e62f0afda5f0a4e8a562f7a13a24cea00ee81917b86b89e801314aa }) is not equal to the last event RuntimeEvent::Referenda(Event::MetadataSet { index: 1, hash: 0xbb30a42c1e62f0afda5f0a4e8a562f7a13a24cea00ee81917b86b89e801314aa })
  left: RuntimeEvent::Referenda(Event::MetadataSet { index: 1, hash: 0xbb30a42c1e62f0afda5f0a4e8a562f7a13a24cea00ee81917b86b89e801314aa })
 right: RuntimeEvent::Referenda(Event::MetadataSet { index: 0, hash: 0xbb30a42c1e62f0afda5f0a4e8a562f7a13a24cea00ee81917b86b89e801314aa })
```

I also improved the error message to include a warning when checking
events on block number zero.

`set_validation_data` register weight manually, do not use refund when the pre dispatch is zero. (#7327)

Related https://github.com/paritytech/polkadot-sdk/issues/6772

For an extrinsic, in the post dispatch info, the actual weight is only
used to reclaim unused weight. If the actual weight is more than the pre
dispatch weight, then the extrinsic is using the minimum, e.g., the
weight used registered in pre dispatch.

In parachain-system pallet one call is `set_validation_data`. This call
is returning an actual weight, but the pre-dispatch weight is 0.

This PR fix the disregard of actual weight of `set_validation_data` by
registering it manually.

The link to Polkachu is not working