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

[xcm-emulator] Parachain's block execution should process only its messages #1388

Open
Tracked by #50
NachoPal opened this issue Sep 4, 2023 · 3 comments
Open
Tracked by #50
Assignees
Labels
T6-XCM This PR/Issue is related to XCM.

Comments

@NachoPal
Copy link
Contributor

NachoPal commented Sep 4, 2023

From paritytech/cumulus#3023 (comment)

Right now, every time a Parchain's block is processed, all stored messages (for all registered Parachains in the Network) are processed.

The side-effecting nature of the code here would likely make it near-impossible to write tests which didn't depend on highly specific implementation details and control flow of the test runner, as well as the ordering of calls to execute_with for different parachains

@bkontur
Copy link
Contributor

bkontur commented Sep 4, 2023

@NachoPal could this be related to the #1127 ?

@NachoPal NachoPal changed the title [xcm-emulator] Parachain's block execution should processed only its messages [xcm-emulator] Parachain's block execution should process only its messages Sep 4, 2023
@NachoPal
Copy link
Contributor Author

NachoPal commented Sep 4, 2023

@NachoPal could this be related to the #1127 ?

Partially yes. The reason why it is happening if because the event pattern matching still works when selecting a different chain. I would say the main reason is the pattern matching. If we can make it work properly, It wouldn't be an issue if other Parachains events are emitted. At the same time, if we make sure that only its own Parachain's messages are processed, it would be impossible to get a match from another Parachain's event.

@0xmovses
Copy link
Contributor

0xmovses commented Nov 2, 2023

Taking a look at this.

@franciscoaguirre franciscoaguirre added the T6-XCM This PR/Issue is related to XCM. label Mar 25, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 8, 2024
* Generalize error text

Right now, each time there is an error while executing `substrate-relay`
it will be reported as:

    ERROR bridge Failed to start relay: <Actual cause of error>

This is the case even if the invoked command did not have anything to do
with starting a relayer. Thus this removes this text. Now something like
this would be written:

    ERROR bridge <Actual cause of error>

* Use substrate-relay prefix
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 8, 2024
* Generalize error text

Right now, each time there is an error while executing `substrate-relay`
it will be reported as:

    ERROR bridge Failed to start relay: <Actual cause of error>

This is the case even if the invoked command did not have anything to do
with starting a relayer. Thus this removes this text. Now something like
this would be written:

    ERROR bridge <Actual cause of error>

* Use substrate-relay prefix
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 8, 2024
* Generalize error text

Right now, each time there is an error while executing `substrate-relay`
it will be reported as:

    ERROR bridge Failed to start relay: <Actual cause of error>

This is the case even if the invoked command did not have anything to do
with starting a relayer. Thus this removes this text. Now something like
this would be written:

    ERROR bridge <Actual cause of error>

* Use substrate-relay prefix
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 8, 2024
* Generalize error text

Right now, each time there is an error while executing `substrate-relay`
it will be reported as:

    ERROR bridge Failed to start relay: <Actual cause of error>

This is the case even if the invoked command did not have anything to do
with starting a relayer. Thus this removes this text. Now something like
this would be written:

    ERROR bridge <Actual cause of error>

* Use substrate-relay prefix
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
* Generalize error text

Right now, each time there is an error while executing `substrate-relay`
it will be reported as:

    ERROR bridge Failed to start relay: <Actual cause of error>

This is the case even if the invoked command did not have anything to do
with starting a relayer. Thus this removes this text. Now something like
this would be written:

    ERROR bridge <Actual cause of error>

* Use substrate-relay prefix
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
* Generalize error text

Right now, each time there is an error while executing `substrate-relay`
it will be reported as:

    ERROR bridge Failed to start relay: <Actual cause of error>

This is the case even if the invoked command did not have anything to do
with starting a relayer. Thus this removes this text. Now something like
this would be written:

    ERROR bridge <Actual cause of error>

* Use substrate-relay prefix
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
* Generalize error text

Right now, each time there is an error while executing `substrate-relay`
it will be reported as:

    ERROR bridge Failed to start relay: <Actual cause of error>

This is the case even if the invoked command did not have anything to do
with starting a relayer. Thus this removes this text. Now something like
this would be written:

    ERROR bridge <Actual cause of error>

* Use substrate-relay prefix
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
* Generalize error text

Right now, each time there is an error while executing `substrate-relay`
it will be reported as:

    ERROR bridge Failed to start relay: <Actual cause of error>

This is the case even if the invoked command did not have anything to do
with starting a relayer. Thus this removes this text. Now something like
this would be written:

    ERROR bridge <Actual cause of error>

* Use substrate-relay prefix
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
* Generalize error text

Right now, each time there is an error while executing `substrate-relay`
it will be reported as:

    ERROR bridge Failed to start relay: <Actual cause of error>

This is the case even if the invoked command did not have anything to do
with starting a relayer. Thus this removes this text. Now something like
this would be written:

    ERROR bridge <Actual cause of error>

* Use substrate-relay prefix
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
* Generalize error text

Right now, each time there is an error while executing `substrate-relay`
it will be reported as:

    ERROR bridge Failed to start relay: <Actual cause of error>

This is the case even if the invoked command did not have anything to do
with starting a relayer. Thus this removes this text. Now something like
this would be written:

    ERROR bridge <Actual cause of error>

* Use substrate-relay prefix
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 10, 2024
* Generalize error text

Right now, each time there is an error while executing `substrate-relay`
it will be reported as:

    ERROR bridge Failed to start relay: <Actual cause of error>

This is the case even if the invoked command did not have anything to do
with starting a relayer. Thus this removes this text. Now something like
this would be written:

    ERROR bridge <Actual cause of error>

* Use substrate-relay prefix
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 10, 2024
* Generalize error text

Right now, each time there is an error while executing `substrate-relay`
it will be reported as:

    ERROR bridge Failed to start relay: <Actual cause of error>

This is the case even if the invoked command did not have anything to do
with starting a relayer. Thus this removes this text. Now something like
this would be written:

    ERROR bridge <Actual cause of error>

* Use substrate-relay prefix
bkchr pushed a commit that referenced this issue Apr 10, 2024
* Generalize error text

Right now, each time there is an error while executing `substrate-relay`
it will be reported as:

    ERROR bridge Failed to start relay: <Actual cause of error>

This is the case even if the invoked command did not have anything to do
with starting a relayer. Thus this removes this text. Now something like
this would be written:

    ERROR bridge <Actual cause of error>

* Use substrate-relay prefix
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T6-XCM This PR/Issue is related to XCM.
Projects
None yet
Development

No branches or pull requests

4 participants