Conversation
- Sending data to a job should always contain a relay parent. Done this for the provisioner - Fixed the `select_availability_bitfields` function. It was assuming we have one core per validator, while we only have one core per parachain. - Drive by async "rewrite" in proposer
bkchr
added
A0-please_review
| self.provisionable_data_channels.push(sender) | ||
| } | ||
| ToJob::Provisioner(ProvisionableData(data)) => { | ||
| ToJob::Provisioner(ProvisionableData(_, data)) => { |
There was a problem hiding this comment.
Why add the relay parent to ProvisionableData if we just ignore it? I see the statement above that sending data to a job should always include that, but it's not obvious why you said that.
There was a problem hiding this comment.
Why is that not obvious? How do you want to know to which job the message needs to be send?
There was a problem hiding this comment.
Nvm, you're right; missed the change in messages.rs.
Co-authored-by: Peter Goodspeed-Niklaus <coriolinus@users.noreply.github.com>
| Self::RequestBlockAuthorshipData(hash, _) => Some(*hash), | ||
| Self::RequestInherentData(hash, _) => Some(*hash), | ||
| Self::ProvisionableData(_) => None, | ||
| Self::ProvisionableData(hash, _) => Some(*hash), |
There was a problem hiding this comment.
Given that most variants of ProvisionableData include a Hash, might it make more sense to just delegate to that hash instead of adding a new one to this enum?
polkadot/node/subsystem/src/messages.rs
Lines 499 to 508 in 23d3de1
There was a problem hiding this comment.
Yeah I thought the same, but I wanted to make it more explicit here. I can also change it
3 participants
for the provisioner
select_availability_bitfieldsfunction. It was assuming wehave one core per validator, while we only have one core per parachain.