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 325
    • Issues 325
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 30
    • Merge requests 30
  • 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
  • #21910
Closed
Open
Issue created Apr 10, 2017 by David Goulet@dgoulet🐼Owner

Refactor connection_edge_process_relay_cell()

Ticket legacy/trac#16706 (moved) is one of the possible many issues we had and will have with this function.

It is quite big with many many return callsite and it is confusing on how it behaves. For instance, if -reason is returned, the caller should teardown the circuit and log warn but yet this functions already does many LOG_PROTOCOL_WARN in that case.

One thing we could do is maybe return a different error code (or set an error code) depending on what's happening (should close circ, cell dropped, error). For instance, currently, returning 0 can either mean that a cell was dropped or successfully relayed.

Auditing every callsite of this function would be important to understand how it is actually used so we can properly improve it and make it less error prone with dubious logging (or improved logging).

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