Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #13484

Closed (moved)
Open
Opened Oct 20, 2014 by Roger Dingledine@arma

Do we have edge cases with rend_consider_descriptor_republication()? Can we refactor it to be cleaner?

Once a second we run rend_consider_descriptor_republication(), which proceeds if anything called router_dir_info_changed(), e.g. if a relay gets marked newly Running or newly not Running.

At first I thought there were bugs here that made us publish our hidden service descriptor much more often than needed. But I think all the logic lines up to only do the publish when we didn't have a microdesc for the relay in question but now we do. But we should see if this is really true.

And even if so, can we refactor this logic to be simpler yet still to retry appropriately if indeed there's a relay we ought to be publishing to? It seems like a lot of overkill for what hopefully will be a rare edge case to begin with. Unless I'm wrong?

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
Tor: unspecified
Milestone
Tor: unspecified
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#13484