Add upward message processing to Paras #1214
Conversation
What case in specific are you worried about? What do you think about introducing a |
Suppose we have messages
That would probably be reasonable, but I need to better understand the difference between XCMP and upwards/downwards. |
Valid concern, but it is easier to handle this at the parachain level. Parachain runtimes need to discard messages they cannot interpret anyway, and in practice they will take care to maintain backwards compatibility. |
Co-authored-by: Bastian Köcher <[email protected]>
gavofyork
added
the
A3-in_progress
|
Some discussion on queue limit sizes (I believe described as Watermarks` in existing code) would be helpful |
Co-authored-by: Robert Habermeier <[email protected]>
montekki
added
the
B0-silent
|
@rphmeier The |
| * `MAX_QUEUE_COUNT` - Total number of messages allowed in the parachain -> relay-chain message queue | ||
| * `WATERMARK_QUEUE_SIZE` - Total size of messages allowed in the parachain -> relay-chain message queue before which no further messages may be added to it. | ||
|
|
||
| In other words, if the queue contains more messages or the total message size in the queue is greater than these contants, `note_new_head` whill fail on the stage of checking the new head. |
There was a problem hiding this comment.
note_new_head happens after availability, whereas we need this check to happen before backing. It's not clear what should happen if note_new_head is fallible - so a candidate could be backed, become available, but then get dropped from the chain because of a queue size check that should have been done earlier?
So it's clear that this size check should be done as part of the process_candidates function of the Inclusion module.
But also, this logic doesn't belong in the paras module. What does it have to do with the head of the chain and validation code upgrades? This logic should go in a new Routing module which will handle upwards/downwards messages and later XCMP logic
4 participants
Biggest question is how the upward message queues work when parachains' code is changed on session boundaries?
Fixes #1138