fix: slot-based collator shuts down immediately after init

[sigurpol]

Fix a regression introduced by #11381, where we wrapped the slot-based collator launch in an async task that first calls wait_for_aura, then spawns the actual long-running collator tasks via slot_based::run(). The wrapper was spawned with spawn_essential_handle().

Essential tasks shut down the node when they complete. The init wrapper completes immediately after spawning, the TaskManager sees an essential task exit, and the node shuts down.

This only affects parachain collators started with --authoring=slot-based.

Fix: use spawn_handle() for the short-lived init wrapper. The child tasks inside slot_based::run() remain correctly marked as essential.

An easy way to reproduce (same setup used by staking-miner nightly test - which in fact started to fail after #11381 got merged e.g. here ): spawn a Zombienet network with a 2-validator relay chain and a single slot-based parachain collator. The collator process starts but shuts down immediately.
For example in your SDK repo:

cd substrate/frame/staking-async/runtimes/papi-tests
just setup
just run fake-dev 

which launches zombienet spawning

• alice (relay validator, port 9944) — polkadot
• bob (relay validator, port 9945) — polkadot
• charlie (parachain collator, port 9946) — polkadot-parachain --collator --authoring=slot-based

Port 9946 never comes up.

I have also verified that the fix coming from #11381 still works, running manually ./target/release/polkadot-parachain --chain asset-hub-polkadot --sync warp --authoring=slot-based --tmp -- --sync warp.

[sigurpol]

/cmd prdoc --audience runtime_dev --bump patch

[sigurpol]

cc @clangenb - PTAL if the change makes sense for you too 🙏

[clangenb]

Yoo, sorry, expected the regular non-warp sync case to be tested in CI here, and I did not wait for the para warp sync to finish when I tested. XD

However, it seems there are relevant scenarios not tested in CI - I guess we should add a follow-up issue to that?

EDIT: Fix looks good obviously

[sigurpol]

Yoo, sorry, expected the regular non-warp sync case to be tested in CI here, and I did not wait for the para warp sync to finish. XD

However, it seems there are relevant scenarios not tested in CI - I guess we should add a follow-up issue to that?

EDIT: Fix looks good obviously

Thanks for the feedback - yes, I believe we could improve coverage on CI definitely, we were discussing for staking to make tests / setup under staking-async/runtimes/papi-tests part of CI eventually but we haven't prioritized that yet --- so independently by that, I think we should probably have this basic use case where we spawn something similar to what I described as part of CI - maybe @pepoviola as zombienet's wizard - together with node experts - you have suggestions / ideas, I am definitely not authoritative here. I have noticed the issue just because the staking-miner nightly job spawns the setup I described in the PR vs latest SDK and starts to fail miserably 😅

[skunert]

Thanks! Missed that indeed. We have zombienet tests for authoring, but they use test-parachain binary. It is used because it has extra CLI flags that are needed for some scenarios. But might be better if we switched to Omni node for the ones that don't require anything special.