Bug Report: Goroutine Handling in libp2p-pubsub Topic "/fil/blocks/"

[frystal]

Checklist

• This is not a security-related bug/issue. If it is, please follow please follow the security policy.
• I have searched on the issue tracker and the lotus forum, and there is no existing related issue or discussion.
• I am running the Latest release, the most recent RC(release canadiate) for the upcoming release or the dev branch(master), or have an issue updating to any of these.
• I did not make any code changes to lotus.

Lotus component

• lotus daemon - chain sync
• lotus fvm/fevm - Lotus FVM and FEVM interactions
• lotus miner/worker - sealing
• lotus miner - proving(WindowPoSt/WinningPoSt)
• lotus JSON-RPC API
• lotus message management (mpool)
• Other

Lotus Version

Daemon:  1.23.3+mainnet+git.7bb1f98ac.dirty+api1.5.0
Local: lotus version 1.23.3+mainnet+git.7bb1f98ac.dirty

Repro Steps

It appears that when the receiving block from the libp2p-pubsub topic "/fil/blocks/" triggers the following code snippet in "/chain/sub/incoming.go":

blk, ok := msg.ValidatorData.(*types.BlockMsg)

If the code snippet fails to perform the type assertion, the code path issues a "return" instead of a "continue", it results in the HandleIncomingBlocks goroutine permanently stopping, and it fails to resume processing.

Describe the Bug

The HandleIncomingBlocks goroutine permanently stops, failing to resume processing.

Logging Information

Not suitable

[magik6k]

So this is actually not possible to trigger in real-world as we always set the correct data in ValidatorData before accepting blocks, but nevertheless this is a good catch, and we should make that code more robust.

[Stebalien]

There's nothing we can do here other than upgrade from a warning to an error and/or panic. If this case happens, there's a bug that shouldn't be ignored.