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
  • #21910

Closed (moved)
Open
Opened Apr 10, 2017 by David Goulet@dgoulet🐋

Refactor connection_edge_process_relay_cell()

Ticket #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
Tor: unspecified
Milestone
Tor: unspecified
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#21910