Polkadot Release Analysis: stable2409-1 & stable2409-2
The following report is not an exhaustive list of changes included in the release, but a set of changes that we felt deserved to be highlighted due to their impact on the Polkadot ecosystem builders.
Please do not stop reading the release notes of Polkadot stable2409-1 & Polkadot stable2409-2. This report is complementary to the changelogs, not a replacement.
There is also a section related to all noteworthy changes related to integration tooling.
Summary
This analysis report is different from other release analysis reports. It contains a combined analysis of minor releases Polkadot stable2409-1 & Polkadot stable2409-2.
There is no major feature added in these releases. However, we are still covering some of the relevant changes included in the Polkadot stable2409-1 & Polkadot stable2409-2. Runtime changes that are part of these releases will be included in the corresponding runtime release done by the fellowship.
All the PRs analyzed in this report are low-impact from a runtime developer perspective.
Next to every PR name you can find the code base related to these changes. The notation is as follows:
- [S]: Changes related to Substrate
- [P]: Changes related to Polkadot
- [C]: Changes related to Cumulus
- [S/P/C]: Changes related to a combination of the noted code bases.
Tooling & Documentation Updates
Polkadot Stable2409-1
[C, P] Remove redundant XCMs from dry run’s forwarded xcms
Why is this important?
This PR addresses the issue of redundant XCM messages appearing in the forwarded_xcms field during dry runs on Asset Hub. The cause was identified as the UpwardMessageSender router incorrectly adding elements even when there were no messages, and the two bridging routers on Asset Hub (Westend) pulling from the same XCMP queue.
The fix ensures that no messages are added when there are none, and clears redundant queue checks for these routers. Additionally, integration tests have been added to verify that only one message is sent to Bridge Hub during a dry-run transfer. This update resolves the redundancy issue while maintaining the flow of bridged messages.
Related Issue: #5878
[S] Fix MQ Pallet low on_idle weight issue
PR: Fix for Issue 4762 by gotnoshoeson · Pull Request #4803 · paritytech/polkadot-sdk · GitHub
Why is this important?
This PR addresses an issue in the MQ pallet where the on_idle hook incorrectly triggered a warning in the service_queues function when there was insufficient weight to process. This behavior was inappropriate, as on_idle should not print defensive errors.
The fix introduces a ServiceQueuesContext enum to differentiate between calls from on_initialize and on_idle. A match statement in service_queues ensures that defensive errors are only triggered when the function is called from on_initialize, and not from on_idle. This update resolves unnecessary warnings and improves the behavior of the MQ pallet.
Related Issue: #4762
[C] Add assets in pool with native to query_acceptable_payment_assets’s return
Why is this important?
This PR enhances the XcmPaymentApi::query_acceptable_payment_assets API by extending its functionality for asset hubs. Previously, this API returned only the native asset (e.g., ROC, WND) as acceptable for fee payments. With this update, the API now also includes assets in a liquidity pool that are paired with the native asset, enabling greater flexibility for fee payments on asset hubs. This change aligns the behavior of the API with the capabilities of the asset conversion pallet, improving payment options for users.
Polkadot Stable2409-2
[P] Fix migrations for pallet-xcm
PR: Fix migrations for pallet-xcm by bkontur · Pull Request #6148 · paritytech/polkadot-sdk · GitHub
Why is this important?
This PR enhances the pallet-xcm by extending the MigrateToLatestXcmVersion to include migration support for the Queries, LockedFungibles, and RemoteLockedFungibles storage types, ensuring compatibility with newer XCM versions.
Additionally, the PR introduces more checks in the try_state function for these storage types. These updates improve the migration process and ensure better handling of XCM messages across different versions, enhancing the stability and flexibility of the pallet
Related Issue: #3214
[S] pallet-message-queue: Fix max message size calculation
Why is this important?
This PR addresses an issue where the maximum message size was incorrectly tied to the remaining weight in a given execution context.
The update ensures that the max message size is based on the service weights configured for the pallet, rather than the available weight in on_idle. This change clarifies that a message not fitting in on_idle is not automatically considered overweight, as it may fit in on_initialize or another block when more weight is available.
The update improves the flexibility and efficiency of the Message Queue Pallet.