Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Tor Tor
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 328
    • Issues 328
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 31
    • Merge requests 31
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Core
  • TorTor
  • Issues
  • #13484
Closed
Open
Issue created Oct 20, 2014 by Roger Dingledine@armaReporter

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 an admin enable hashed storage. More information
Assignee
Assign to
Time tracking