Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #24661
Closed (moved) (moved)
Open
Issue created Dec 18, 2017 by Taylor Yu@catalyst

accept a reasonably live consensus for guard selection

Clients with clocks skewed far enough in the future to never get a live consensus, but still have a reasonably live one, end up downloading descriptors and then getting stuck on guard selection. This is a rather bad user experience because bootstrap progress appears to get stuck at 80% or 85% even though something rather fundamental (time of day) is wrong.

It's not clear that a reasonably live consensus is dangerous to use for guard selection, so always accept a reasonably live consensus instead of a live one for guard selection.

Ticket #2878 (moved) covers the case of deferring descriptor downloads if the consensus isn't live, which would also improve the UX but might not be necessary if we implement the solution in this ticket.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking