Make WeightBounds return XcmError to surface failures#8535
Merged
raymondkfcheung merged 31 commits intomasterfrom May 29, 2025
Merged
Make WeightBounds return XcmError to surface failures#8535raymondkfcheung merged 31 commits intomasterfrom
WeightBounds return XcmError to surface failures#8535raymondkfcheung merged 31 commits intomasterfrom
Conversation
Contributor
Author
|
/cmd prdoc --audience runtime_dev --bump patch |
…time_dev --bump patch'
|
All GitHub workflows were cancelled due to failure one of the required jobs. |
acatangiu
approved these changes
May 27, 2025
| /// Return the maximum amount of weight that an attempted execution of this message could | ||
| /// consume. | ||
| fn weight(message: &mut Xcm<RuntimeCall>) -> Result<Weight, ()>; | ||
| fn weight(message: &mut Xcm<RuntimeCall>) -> Result<Weight, XcmError>; |
Contributor
There was a problem hiding this comment.
Can we make this return the index of the problematic instruction as well? It'd be very useful to bubble it up in #7730
x3c41a
approved these changes
May 29, 2025
| polkadot-runtime-parachains = { workspace = true, default-features = true } | ||
| polkadot-test-runtime = { workspace = true } | ||
| primitive-types = { features = ["codec", "num-traits", "scale-info"], workspace = true } | ||
| sp-tracing = { features = ["test-utils"], workspace = true, default-features = true } |
Contributor
There was a problem hiding this comment.
just curious why you add sp-tracing as a dev dependency not as a regular one?
github-project-automation
bot
moved this from To be released (SDK)
to Integrated - Done
in fellowship/runtimes integrations queue
bkontur
moved this from Integrated - Done
to To be released (SDK)
in fellowship/runtimes integrations queue
39 tasks
pgherveou
pushed a commit
that referenced
this pull request
Jun 11, 2025
This PR partially addresses #8419 by improving error handling and traceability for XCM weight calculation failures in `WeightInfoBounds` and `FixedWeightBounds`. ## Why change The vague "Failed to prepare message" error in #8419 makes debugging extremely difficult. The current implementation drops detailed errors and omits log context, especially for cases like decoding instructions or violating instruction count limits. Previously, XCM weight calculation errors were surfaced only as `Result<Weight, ()>`, losing valuable error information and forcing all upstream consumers to treat them as opaque failures. ## How change * Updates return types: Changes `WeightBounds::weight` and `instr_weight` to return `Result<Weight, XcmError>` instead of `Result<Weight, ()>` * Improves internal error handling: Uses `Result<Weight, XcmError>` internally for: - Instruction decoding failures → `FailedToDecode` - Message/instruction weight overflows → `Overflow` - Excessive instruction count → `ExceedsStackLimit` * Adds structured debug logging: - `weight`: logs error type, instructions remaining, message length - `instr_weight`: logs error type, instruction, and limit * Updates consumers: Ensures downstream callers (e.g., `XcmExecutor`, `ExecuteXcm`) properly handle the structured errors This enables better structured error handling and debugging while providing detailed context for XCM weight calculation failures. --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
alvicsam
pushed a commit
that referenced
this pull request
Oct 17, 2025
This PR partially addresses #8419 by improving error handling and traceability for XCM weight calculation failures in `WeightInfoBounds` and `FixedWeightBounds`. ## Why change The vague "Failed to prepare message" error in #8419 makes debugging extremely difficult. The current implementation drops detailed errors and omits log context, especially for cases like decoding instructions or violating instruction count limits. Previously, XCM weight calculation errors were surfaced only as `Result<Weight, ()>`, losing valuable error information and forcing all upstream consumers to treat them as opaque failures. ## How change * Updates return types: Changes `WeightBounds::weight` and `instr_weight` to return `Result<Weight, XcmError>` instead of `Result<Weight, ()>` * Improves internal error handling: Uses `Result<Weight, XcmError>` internally for: - Instruction decoding failures → `FailedToDecode` - Message/instruction weight overflows → `Overflow` - Excessive instruction count → `ExceedsStackLimit` * Adds structured debug logging: - `weight`: logs error type, instructions remaining, message length - `instr_weight`: logs error type, instruction, and limit * Updates consumers: Ensures downstream callers (e.g., `XcmExecutor`, `ExecuteXcm`) properly handle the structured errors This enables better structured error handling and debugging while providing detailed context for XCM weight calculation failures. --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
6 tasks
6 tasks
snowmead
added a commit
to Moonsong-Labs/storage-hub
that referenced
this pull request
Mar 16, 2026
Upgrade all polkadot-sdk git dependencies from branch `stable2503` to `stable2506`. Upgrade all Frontier EVM dependencies from branch `stable2503` to tag `frontier-stable2506`. Fix all compilation errors and test failures caused by upstream breaking API changes in polkadot-sdk stable2506 (134 PRs) and 9 patch releases. Upstream breaking changes addressed: - Remove local `AccountIdFor` alias, now provided by `frame_system::pallet_prelude` (paritytech/polkadot-sdk#7229) - Add `RelayParentOffset = ConstU32<0>` to parachain system config (paritytech/polkadot-sdk#8299) - Fix `Outcome` enum pattern matching: `Error` is now tuple variant wrapping `InstructionError` (paritytech/polkadot-sdk#8535) - Remove `RuntimeEvent` from `pallet_evm::Config` and `pallet_ethereum::Config` (frontier stable2506) - Add `RuntimeEvent` to `pallet_session::historical::Config` - Remove `PassByInner` import, use `.0` for `H256` inner access (paritytech/polkadot-sdk#7375) - Destructure 4 return values from `build_relay_chain_interface` (paritytech/polkadot-sdk#8072) - Add `metrics` field to `BuildNetworkParams` (paritytech/polkadot-sdk#8332) - Add `prometheus_registry` to `StartRelayChainTasksParams` (paritytech/polkadot-sdk#8332) Release: https://github.com/paritytech/polkadot-sdk/releases/tag/polkadot-stable2506 Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR partially addresses #8419 by improving error handling and traceability for XCM weight calculation failures in
WeightInfoBoundsandFixedWeightBounds.Why change
The vague "Failed to prepare message" error in #8419 makes debugging extremely difficult. The current implementation drops detailed errors and omits log context, especially for cases like decoding instructions or violating instruction count limits. Previously, XCM weight calculation errors were surfaced only as
Result<Weight, ()>, losing valuable error information and forcing all upstream consumers to treat them as opaque failures.How change
WeightBounds::weightandinstr_weightto returnResult<Weight, XcmError>instead ofResult<Weight, ()>Result<Weight, XcmError>internally for:FailedToDecodeOverflowExceedsStackLimitweight: logs error type, instructions remaining, message lengthinstr_weight: logs error type, instruction, and limitXcmExecutor,ExecuteXcm) properly handle the structured errorsThis enables better structured error handling and debugging while providing detailed context for XCM weight calculation failures.