Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[stable2409] Backport #5712 #5764

Merged
merged 1 commit into from
Sep 19, 2024
Merged

Conversation

paritytech-cmd-bot-polkadot-sdk[bot]

Backport #5712 into stable2409 from franciscoaguirre.

See the documentation on how to use this bot.

When running XCM emulated tests and seeing the logs with `RUST_LOG=xcm`
or `RUST_LOG=xcm=trace`, it's sometimes a bit hard to figure out the
chain where the logs are coming from.

I added a log whenever `execute_with` is called, to know the chain which
makes the following logs. Looks like so:

<img width="1499" alt="Screenshot 2024-09-13 at 20 14 13"
src="https://github.com/user-attachments/assets/a31d7aa4-11d1-4d3e-9a65-86f38347c880">

There are already log targets for when UMP, DMP and HRMP messages are
being processed. To see them, you have to use the log targets `ump`,
`dmp`, and `hrmp` respectively. So `RUST_LOG=xcm,ump,dmp,hrmp` would let
you see every log.
I prefixed the targets with `xcm::` so you can get all the relevant logs
just by filtering by `xcm`. You can always use the whole target to see
just the messages being processed.

These logs showed the message as an array of bytes, I made them show a
hexadecimal string instead since that's easier to copy in case you want
to decode it or use it in another tool. They look like this now:

<img width="1499" alt="Screenshot 2024-09-13 at 20 17 15"
src="https://github.com/user-attachments/assets/5abf4a97-1ea7-4832-b3b0-d54c54905d1a">

The HRMP and UMP ones are very similar.

(cherry picked from commit b230b0e)
Copy link
Contributor

This pull request is amending an existing release. Please proceed with extreme caution,
as to not impact downstream teams that rely on the stability of it. Some things to consider:

  • Backports are only for 'patch' or 'minor' changes. No 'major' or other breaking change.
  • Should be a legit fix for some bug, not adding tons of new features.
  • Must either be already audited or not need an audit.
Emergency Bypass

If you really need to bypass this check: add validate: false to each crate
in the Prdoc where a breaking change is introduced. This will release a new major
version of that crate and all its reverse dependencies and basically break the release.

@acatangiu acatangiu merged commit 56ce901 into stable2409 Sep 19, 2024
100 of 141 checks passed
@acatangiu acatangiu deleted the backport-5712-to-stable2409 branch September 19, 2024 07:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A3-backport Pull request is already reviewed well in another branch.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants