xcm-builder: added logging for xcm filters/helpers/matchers/types (#2408)#7003
Merged
acatangiu merged 80 commits intoparitytech:masterfrom Feb 21, 2025
Merged
xcm-builder: added logging for xcm filters/helpers/matchers/types (#2408)#7003acatangiu merged 80 commits intoparitytech:masterfrom
acatangiu merged 80 commits intoparitytech:masterfrom
Conversation
ayevbeosa
changed the title
added 15 commits
December 26, 2024 08:25
bkchr
reviewed
Dec 27, 2024
Member
bkchr
left a comment
bkchr
left a comment
There was a problem hiding this comment.
Can you please change all these calls to follow the same pattern as shown by me in teh suggestions?
cumulus/parachains/runtimes/assets/common/src/fungible_conversion.rs
Outdated
Show resolved
Hide resolved
…ion.rs Co-authored-by: Bastian Köcher <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>
Co-authored-by: Bastian Köcher <[email protected]>
…a/polkadot-sdk into ayevbeosa-more-xcm-logs
|
@acatangiu A referendum for a small (20 DOT) tip was successfully submitted for @ayevbeosa (1Gz5aLtEu2n4jsfA6XwtZnuaRymJrDDw4kEGdNHTdxrpzrc on polkadot). Referendum number: 1451. |
|
The referendum has appeared on Polkassembly. |
Contributor
|
/cmd fmt |
Merged
via the queue into
paritytech:master
with commit Feb 21, 2025
934c091
237 of 254 checks passed
raymondkfcheung
moved this to To be released (SDK)
in fellowship/runtimes integrations queue
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jun 4, 2025
This PR enhances diagnostics across XCM-related components by implementing more detailed logging, especially for failures. The primary aim is to improve visibility into XCM errors (e.g., within `map_err` blocks), enabling faster troubleshooting for developers and node operators. Key enhancements include: * Logging specific error conditions (e.g., `BadVersion`, `BadLocation`, execution errors). * Including essential context in error logs (e.g., message hashes, origin, destination, relevant parameters). * Standardising log targets for easier analysis (e.g., `xcm::module::function_name`). * Clarifying log messages. This work continues #7003 and partially addresses #6119. ## Integration Downstream projects using XCM functionalities should see improved diagnostic logs without needing direct integration changes, as this primarily enhances internal logging. Node operators will find new, more detailed XCM error logs, aiding in monitoring and troubleshooting. Log parsing scripts might need updates for new log formats. ## Review Notes This PR enhances logging throughout XCM-related code paths, particularly in error handling (e.g., `map_err` blocks), to improve failure visibility. Reviewers are encouraged to assess: * **Clarity & Actionability:** Are logs clear, concise, and actionable for failures? * **Context:** Do error logs capture essential context (message hash, origin, destination, error specifics, parameters) appropriately for their level? * **Log Levels:** Is the chosen log level (e.g., `error`, `warn`, `debug`, `trace`) suitable? Are any level adjustments appropriate? * **Targets:** Are `target:` fields (e.g., `xcm::module::function`) consistent and specific? * **Error Accuracy:** Do logs accurately reflect the handled error condition? * **Impact:** Logging should minimally affect core logic and performance; favour simple logging of existing/easily derived data. --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
7 tasks
pgherveou
pushed a commit
that referenced
this pull request
Jun 11, 2025
This PR enhances diagnostics across XCM-related components by implementing more detailed logging, especially for failures. The primary aim is to improve visibility into XCM errors (e.g., within `map_err` blocks), enabling faster troubleshooting for developers and node operators. Key enhancements include: * Logging specific error conditions (e.g., `BadVersion`, `BadLocation`, execution errors). * Including essential context in error logs (e.g., message hashes, origin, destination, relevant parameters). * Standardising log targets for easier analysis (e.g., `xcm::module::function_name`). * Clarifying log messages. This work continues #7003 and partially addresses #6119. ## Integration Downstream projects using XCM functionalities should see improved diagnostic logs without needing direct integration changes, as this primarily enhances internal logging. Node operators will find new, more detailed XCM error logs, aiding in monitoring and troubleshooting. Log parsing scripts might need updates for new log formats. ## Review Notes This PR enhances logging throughout XCM-related code paths, particularly in error handling (e.g., `map_err` blocks), to improve failure visibility. Reviewers are encouraged to assess: * **Clarity & Actionability:** Are logs clear, concise, and actionable for failures? * **Context:** Do error logs capture essential context (message hash, origin, destination, error specifics, parameters) appropriately for their level? * **Log Levels:** Is the chosen log level (e.g., `error`, `warn`, `debug`, `trace`) suitable? Are any level adjustments appropriate? * **Targets:** Are `target:` fields (e.g., `xcm::module::function`) consistent and specific? * **Error Accuracy:** Do logs accurately reflect the handled error condition? * **Impact:** Logging should minimally affect core logic and performance; favour simple logging of existing/easily derived data. --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
acatangiu
moved this from To be released (SDK)
to SDK Released - Needs Integration
in fellowship/runtimes integrations queue
This was referenced Jul 16, 2025
alvicsam
pushed a commit
that referenced
this pull request
Oct 17, 2025
This PR enhances diagnostics across XCM-related components by implementing more detailed logging, especially for failures. The primary aim is to improve visibility into XCM errors (e.g., within `map_err` blocks), enabling faster troubleshooting for developers and node operators. Key enhancements include: * Logging specific error conditions (e.g., `BadVersion`, `BadLocation`, execution errors). * Including essential context in error logs (e.g., message hashes, origin, destination, relevant parameters). * Standardising log targets for easier analysis (e.g., `xcm::module::function_name`). * Clarifying log messages. This work continues #7003 and partially addresses #6119. ## Integration Downstream projects using XCM functionalities should see improved diagnostic logs without needing direct integration changes, as this primarily enhances internal logging. Node operators will find new, more detailed XCM error logs, aiding in monitoring and troubleshooting. Log parsing scripts might need updates for new log formats. ## Review Notes This PR enhances logging throughout XCM-related code paths, particularly in error handling (e.g., `map_err` blocks), to improve failure visibility. Reviewers are encouraged to assess: * **Clarity & Actionability:** Are logs clear, concise, and actionable for failures? * **Context:** Do error logs capture essential context (message hash, origin, destination, error specifics, parameters) appropriately for their level? * **Log Levels:** Is the chosen log level (e.g., `error`, `warn`, `debug`, `trace`) suitable? Are any level adjustments appropriate? * **Targets:** Are `target:` fields (e.g., `xcm::module::function`) consistent and specific? * **Error Accuracy:** Do logs accurately reflect the handled error condition? * **Impact:** Logging should minimally affect core logic and performance; favour simple logging of existing/easily derived data. --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
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
5 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.
Description
Added logs in pallet-xcm to help in debugging, fixes #2408, and in continuation of #4982
Checklist
Polkadot Address: 1Gz5aLtEu2n4jsfA6XwtZnuaRymJrDDw4kEGdNHTdxrpzrc