fix: prevent progress bar from panicking using workaround

[conradoplg]

Motivation

Running Zebra with progress bar makes it panic after a while.

This seems to be caused by a bug in howudoin/indicatif where if a progress bar gets stuck, the ETA keeps growing and growing until it overflows. I'll eventually try to get a simple reproducer and report it, but in the meantime we can do a workaround.

Solution

This removes the limit on the progress bars that are not guaranteed to complete, which removes the ETA and avoids the panic. The other progress bars (e.g. Blocks) could still panic if the node gets offline but this seems enough for now.

We could copy&paste and modify the TermLine implementation from howudoin to not display the ETA, but seems more work and would duplicate code.

They look like this with this PR:

 | Known Peers: 70                                                                                                    
 | Failed Peers: 3                                                                                                    
 | Inbound Connections: 0                                                                                             
 | Outbound Connections: 39                                                                                           
 / Queued Checkpoint Blocks (6y)
 [=============================>]  99% (2092738/2112016)                                                              
 / Verified Checkpoints (39w)
 [=============================>]  99% (10795/10875)                                                                  
 / Blocks (2h)
 [=============================>]  99% (2091696/2120401) Nu5                                                          
 | Never Attempted Peers: 27                                                             

Closes #6926

Review

This is not urgent since progress bars are optional. But I think it would be nice to get this in the stable release so that we can show the progress bars working during demos.

Anyone can review.

Reviewer Checklist

• Will the PR name make sense to users?
  • Does it need extra CHANGELOG info? (new features, breaking changes, large changes)
• Are the PR labels correct?
• Does the code do what the ticket and PR says?
  • Does it change concurrent code, unsafe code, or consensus rules?
• How do you know it works? Does it have tests?

Follow Up Work

Need to report the bug in indicatif (and maybe propose a PR to fix), will do that later

[codecov]

Codecov Report

Merging #6940 (e9ec8ce) into main (c058f77) will increase coverage by 0.06%.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6940      +/-   ##
==========================================
+ Coverage   77.59%   77.66%   +0.06%     
==========================================
  Files         310      310              
  Lines       41475    41463      -12     
==========================================
+ Hits        32183    32201      +18     
+ Misses       9292     9262      -30     

[teor2345]

Thanks for this fix!

I think we should restart the Zebra instance before the demo as a workaround.

The long-term fix would be disabling the ETA on those progress bars (an API change), and fixing the overflow bug in those libraries. But that's not a priority right now.

Would you mind moving these limits into comments? It's important that we document them anyway, and we might as well refer to the existing constants.

[conradoplg]

Thanks for this fix!

I think we should restart the Zebra instance before the demo as a workaround.

It takes 4m30s to crash on my machine, so that may lead to a very stressful demo 😅
This seems a very low risk change, but it's up to you. We can always cherry pick this when doing any demos.

Would you mind moving these limits into comments? It's important that we document them anyway, and we might as well refer to the existing constants.

Done in 74365c4

[teor2345]

Thanks for this fix!
I think we should restart the Zebra instance before the demo as a workaround.

It takes 4m30s to crash on my machine, so that may lead to a very stressful demo 😅 This seems a very low risk change, but it's up to you. We can always cherry pick this when doing any demos.

Oh wow, that's not what was happening when I wrote the feature. This seems like a new bug in the libraries we're using.

[teor2345]

Thanks for the fix!