Fix protocol handler retrieval thread CPU usage when no blocks are pr…

[sydhds]

…ocessed

• document all added functions
• try in sandbox /simulation/labnet
  • if part of node-launch, checked using the resync_check flag
• unit tests on the added/changed features
  • make tests compile
  • make tests pass
• add logs allowing easy debugging in case the changes caused problems
• if the API has changed, update the API specification

[bilboquet]

Solves the problem on my side.
Tracing the tokio loop from which this function is called shows that branches from the select are taken each second.

[damip]

Nice catch !
TODO: fix comment, shorten all thread names to fit

[damip]

@sydhds @bilboquet @AurelienFT Does this require an urgent 1.1 deployment ? or does it have no impact at genesis ?

[codecov]

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (4563909) 71.78% compared to head (13948e6) 71.78%.

Files	Patch %	Lines
massa-protocol-worker/src/connectivity.rs	50.00%	1 Missing ⚠️
...l-worker/src/handlers/block_handler/propagation.rs	50.00%	1 Missing ⚠️
...col-worker/src/handlers/block_handler/retrieval.rs	80.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4617   +/-   ##
=======================================
  Coverage   71.78%   71.78%           
=======================================
  Files         291      291           
  Lines       51642    51642           
=======================================
  Hits        37069    37069           
  Misses      14573    14573           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[AurelienFT]

@sydhds @bilboquet @AurelienFT Does this require an urgent 1.1 deployment ? or does it have no impact at genesis ?

No it should stop when blocks will be produced. Could be cool to verify with a labnet

[Floyz]

@sydhds @bilboquet @AurelienFT Does this require an urgent 1.1 deployment ? or does it have no impact at genesis ?

No it should stop when blocks will be produced. Could be cool to verify with a labnet

It has impact on node runners hardware tho, if you want people to have node running before genesis it would be great to publish a new release.
I stopped mine due to this bug, consuming one full CPU for nothing and impacting other services on a shared hardware. ( + CPU temp going high )

[bilboquet]

@sydhds @bilboquet @AurelienFT Does this require an urgent 1.1 deployment ? or does it have no impact at genesis ?

No it should stop when blocks will be produced. Could be cool to verify with a labnet

It has impact on node runners hardware tho, if you want people to have node running before genesis it would be great to publish a new release. I stopped mine due to this bug, consuming one full CPU for nothing and impacting other services on a shared hardware. ( + CPU temp going high )

Reproduced in sandbox.
Behavior is exactly the same as with mainnet (with or without the fix).

In labnet (thanks to @Leo-Besancon) the behavior is the one expected and stated above by @AurelienFT:

• when blocks are produced, the load goes back to normal
• the only corner case observed so far is: if there is only one node in the network that produces blocks, this node, and only it, will experience the bug.

[damip]

Good !