Skip building on blocks on relay parents in old session

[Sajjon]

Fixes: #9977

On our Kusama Canary chain YAP-3392 has the log entry:

Collation wasn't advertised because it was built on a relay chain block that is now part of an old session

show up 400+ times (2025-10-03 -- 2025-10-10).

Changes

Changed offset_relay_parent_find_descendants to return None if the relay_best_hash or any of its ancestors contains an epoch change.

[sandreim]

I think we can do better than this and have some separation of concerns and more robust check. We should actually query the collator protocol and ask it if we can use a specific relay parent.

Please look at distribute_collation as there are multiple checks there on the relay parent which we can do before we decide to create a collation on it.

Also, we should keep in mind that advertisement can actually happen later, and by that time the relay parent might not be valid anymore, if a new block was created in a new session. This means that what we do here will not always prevent the situation from happening.

[sandreim]

you already relay_best_hash this in the caller scope, you can just pass it to the fn

[Sajjon]

@sandreim can you expand a bit on your last message / explain more what you had in mind.

I'll call checking if relay parent is in old session for SessionBoundryCheck

We should actually query the collator protocol and ask it if we can use a specific relay parent.

From where should we query the collator protocol? Later you say:

This means that what we do here will not always prevent the situation from happening.

Thus you make it sound like performing SessionBoundryCheck inside run_block_builder is wrong? Or do you mean it is wrong to only performing SessionBoundryCheck there? So perhaps do it in multiple places?

• before building (my attempt of doing so is my current impl, inside: run_block_builder)
• after building but before advertisment
• some more place/time?

Please look at distribute_collation as there are multiple checks there on the relay parent which we can do before we decide to create a collation on it.

Hmm did you mean I should perform SessionBoundryCheck inside distribute_collation? Because that feels much too late? That function is called with a candidate, thus we have already built, but this issue is about not even building the block.

By "query the collator protocol", do you mean adding a method to the trait ServiceInterface? And call it through like we do here in basic aura, like so:

collator.collator_service().some_function()

I feel properly confused now 😅

[skunert]

I thought we wanted to fix this on the relay chain side? #9766

I have a check here which already checks whether there will be an epoch change in the relay parent ancestry. If yes, I am including the next epochs authorities for verification. Currently these blocks are getting dropped anyway, so the implementation is already forward looking, because I assumed at some point we will not drop anymore 😬.

[Sajjon]

@skunert

I thought we wanted to fix this on the relay chain side?

We want to avoid even building the parablock in the first place, to not waste resources (degrading block confidence), so it must happen on parachain side then, right?

[skunert]

@skunert

I thought we wanted to fix this on the relay chain side?

We want to avoid even building the parablock in the first place, to not waste resources (degrading block confidence), so it must happen on parachain side then, right?

Confidence is dropping because we drop candidates at session boundaries. If we wouldn't do that, confidence would not reduce and parachains could keep producing blocks as they do now right? #9766

But yeah I assume it takes too long or is not scheduled?

[sandreim]

@skunert

I thought we wanted to fix this on the relay chain side?

We want to avoid even building the parablock in the first place, to not waste resources (degrading block confidence), so it must happen on parachain side then, right?

Confidence is dropping because we drop candidates at session boundaries. If we wouldn't do that, confidence would not reduce and parachains could keep producing blocks as they do now right? #9766

But yeah I assume it takes too long or is not scheduled?

#9766 is a different issue. If you read the ticket it is about candidates that have already been backed on chain and are pending availability. To solve that one we need to fix availability.

The issue in #9977 is that these candidates are not even advertised by collator protocol because the relay parent is out of scope already. To properly fix it we need to allow candidates with relay parents from the previous session. The fix should require changes in collator protocol, backing and prospective-parachains.

We will need to do this for supporting low latency parachains. IIRC we discussed with @eskimor about decoupling the relay parent we use for execution context from the one we use for scheduling information.

The fix in this PR should be very easy but will not be perfect. The candidate could be fetched because a new session was not observed yet, but then dropped from prospective parachains as soon as the RC advances in new session. What we can do for now is not build a collation on an older RP if we've already seen the RC best block in new session.

I have a check here which already checks whether there will be an epoch change in the relay parent ancestry. If yes, I am including the next epochs authorities for verification. Currently these blocks are getting dropped anyway, so the implementation is already forward looking, because I assumed at some point we will not drop anymore 😬.

I am not familiar with this code, does it solve what I said above ?

Also I don't think this should be solved in the cumulus code, because of separation of concerns. That's why I am proposing to query the collator protocol subsystem to do a sanity check on the relay parent before proceeding with block production. When we will allow RPs from prev session, you won't need to change anything in cumulus.

[sandreim]

Thus you make it sound like performing SessionBoundryCheck inside run_block_builder is wrong? Or do you mean it is wrong to only performing SessionBoundryCheck there? So perhaps do it in multiple places?

• before building (my attempt of doing so is my current impl, inside: run_block_builder)

Yes, before, I propose you send a message to collator-protocol subsystem and ask it to tell you if the relay_parent is good to be built on. Collator protocol already tracks sessions and contains more checks for RP.

[skunert]

The check I mentioned above checks if any of the RP descendants we use to enforce the offset contain a session change digest. If they do, we include additional relay chain authorities in the inherent storage proof. I did this because I was assuming that we will allow relay parents from old sessions at some point. So it does currently not fix the issue you want to fix. But the check can be used for this, because the condition is the same.

The concerns of finding the correct relay parent are currently not separated anyway. We have the parent_search which tries to find a suitable parent block which lives in the same session as the tip of the chain. While thinking about this issue here I realized that we pass the relay_parent into this instead of the tip of the chain.

---

So I think what we should do is:

• Pass the relay_best_hash here instead of relay_parent. This should enforce that the relay parent ancestry contains only blocks which we have no parachain blocks for, essentially leading to skipping the block.
• However, we need to ensure that the included_header_hash here corresponds to the included hash from the relay_parent, same as it is now. Otherwise the runtime will later perform its checks against a different included block than what we check during authoring.

[Sajjon]

@skunert @sandreim I've tried the approach proposed by Sebastian (at least according to my potentially flawed understand of his instructions) and I've run Zombienet tests with these changes, and it did NOT fix the issue, see changes below:

Then I've re-applied my implementation from 2 weeks ago, and ran the same Zombienet tests, and it DOES solve the issue.

I've probably misunderstood Sebastians input... but yeah I'm blocked until further input.

[Sajjon]

I've verified that this PR fixes the issue by running ZN test.

I've also added some unit tests of offset_relay_parent_find_descendants.

[sandreim]

Can we also enhance an existing ZN test ensuring that we don't build on prev session relay parent ?

[sandreim]

That is true, but doesn't fully help debug if you don't have much context. I'd make the log more explicit like this:

Suggested change

	tracing::debug!(target: LOG_TARGET, ?relay_best_block, "Relay header contains epoch change.");
	tracing::debug!(target: LOG_TARGET, ?relay_best_block, "Relay parent is in previous session");

[skunert]

Lets also log the relay block number here. When reading the logs we don't have to do the mapping to see at which height we are. Started to do this more and more. Even though technically not necessary it makes debugging easier.

[sandreim]

Also here.

[sandreim]

Is there any place we actually log the reason we are not building a block ?

[skunert]

Inside offset_relay_parent_find_descendants there is logging.
I agree that for each abort reason there should be at least some message telling why we skipped. Either inside the helpers or here in the main loop.

[Sajjon]

Instead of Option<RelayParentData> I can use a specific enum with more contextual information, perhaps (please help with naming):

+ enum RelayParentDescendantsSearchOutcome {
+ 	/// A potentially suitable relay parent to build upon.
+ 	Data(RelayParentData)
+ 	/// We should not build on this relay parent, it is in an old session
+ 	RelayParentIsInPreviousSession
+ }

	async fn offset_relay_parent_find_descendants<RelayClient>(
	 // args omitted
-	) -> Result<Option<RelayParentData>, ()> {
+	) -> Result<RelayParentDescendantsSearchOutcome, ()> {
		...
		if relay_parent_offset == 0 {
-			return Ok(Some(RelayParentData::new(relay_header)));
+			return Ok(RelayParentDescendantsSearchOutcome::Data(RelayParentData::new(relay_header)));
		}

		if sc_consensus_babe::contains_epoch_change::<RelayBlock>(&relay_header) {
			...
-			return Ok(None);
+			return Ok(RelayParentDescendantsSearchOutcome::RelayParentIsInPreviousSession);
		}
		...
		while required_ancestors.len() < relay_parent_offset as usize {
			...
			if sc_consensus_babe::contains_epoch_change::<RelayBlock>(&next_header) {
				...
-				return Ok(None);
+				return Ok(RelayParentDescendantsSearchOutcome::RelayParentIsInPreviousSession);
			}
			...
		}
		...
-		Ok(Some(RelayParentData::new_with_descendants(relay_parent, required_ancestors.into())))
+		Ok(RelayParentDescendantsSearchOutcome::Data(RelayParentData::new_with_descendants(relay_parent, required_ancestors.into())))
	}

[skunert]

Only nits, looks good.

[skunert]

Inside offset_relay_parent_find_descendants there is logging.
I agree that for each abort reason there should be at least some message telling why we skipped. Either inside the helpers or here in the main loop.

[skunert]

Lets also log the relay block number here. When reading the logs we don't have to do the mapping to see at which height we are. Started to do this more and more. Even though technically not necessary it makes debugging easier.

[skunert]

Nice tests!

One nitpick is that you could use rstest, example here:

polkadot-sdk/cumulus/pallets/parachain-system/src/descendant_validation.rs

Line 289 in 9fb3757

#[case::too_many_2(100)]

I like that the parameterization makes the file a bit shorter. But optional, do as you like here.

[Sajjon]

Of course, nice, I did not know we had used rstest before (I'm a bit careful assuming I can just add any crate as a dependency).

[paritytech-workflow-stopper]

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/18774295803
Failed job name: fmt

[Sajjon]

Can we also enhance an existing ZN test ensuring that we don't build on prev session relay parent ?

On it! I need to understand how I best add new ZN tests using the "new" ZN crate (over ZN binary and toml/zndsl files), I've asked here

[sandreim]

thanks @Sajjon !

@skunert , I'd say we merge this one so it gets into release and the test can go in later.

I've been running this change for a couple of days in Kusama and works nicely.