Core Index Mismatch in Commitments and Descriptor

[sw10pa]

Description

A bug was identified during the implementation of the malus collator using undying collator (PR #6924). The following error message was observed from the collation-generation subsystem when the normal (non-malus) undying collator attempted to generate and submit collations to 3 assigned cores:

ERROR tokio-runtime-worker parachain::collation-generation: Failed to construct and distribute collation: V2 core index check failed: The core index in commitments doesn't match the one in descriptor.

The issue arises because the current code provides core indexes sequentially from the claim queue for the descriptor, while the commitments can include core indexes determined by the parachain using a core selector from UMP signals, potentially in a different sequence. This mismatch leads to the observed error.

Steps to Reproduce

• Set up a network with an undying collator;
• Ensure that the parachain is assigned to 3 or more cores;
• Configure the core indexes to be provided by UMP signals.

Why was this not detected earlier?

• Test collators (e.g., adder and undying) were not using UMP signals, as they are optional;
• Elastic scaling collators (e.g., slot-based collators) do not have this problem, as it was addressed in PR #5372;
• UMP signals are a new thing and collators using collator_fn have not been tested much, as they should not be used in production.

Proposed Solution

• Modify the logic for constructing the CandidateDescriptorV2 to get the core index from commitments (via UMP signals) instead of using sequential indexes got from the claim queue;
• Ensure backward compatibility for parachains that do not use UMP signals, allowing the system to function as before in those cases;
• Add a check to stop processing if the parachain selects the same core multiple times when multiple cores are assigned.