Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • 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
  • #33067

Closed (moved)
(moved)
Open
Created Jan 27, 2020 by Roger Dingledine@arma

DocTor should fetch microdesc consensus

Currently the consensus health (DocTor) scripts try to fetch the vanilla consensus from the dirport of each directory authority.

That's useful to look at, because relays try to fetch it too.

But it is at least as useful, and arguably more useful, to fetch the microdesc-flavored consensus and make sure that one is working too.

I mention this idea now because with the #33018 (moved) and #33029 (moved) fixes, directory authorities might end up giving priority to answering microdesc consensus requests over vanilla consensus requests when we are bandwidth constrained and we need to choose.

(I don't want to add a special case to the Tor code to never send a 503 to the consensus health checker IP address, because that would just mask any actual problems that the rest of the network would experience.)

(We might later decide that it's no longer wise to send an email warning when consensus-health's vanilla consensus request gets a 503 response. Those emails will be unactionable and just make people stop reading emails from consensus-health. But we can tackle that one once we resolve #33029 (moved).)

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