mirrors/arti.git/crates/tor-proto/src/circuit/reactor, branch main

tor-proto: disable flowctrl sidechannel mitigations for relays

2026-08-19T17:29:14Z

The end result should be: 1. outgoing streams - enable sidechannel mitigations 2. incoming hs streams - enable sidechannel mitigations 3. incoming exit streams - disable sidechannel mitigations

tor-proto: add `StreamHandler::flowctrl_sidechannel_mitigations()`

2026-08-19T17:27:23Z

proto: Add {backward|forward} prefix to circ_id in logs

2026-08-03T18:27:50Z

Signed-off-by: David Goulet

proto: Rename uniq_id to circ_unique_id mostly in logging

2026-08-03T18:27:50Z

We have decided that instead of "uniq_id" in logging, we'll use the "-[]-id" syntax to indicate who is that unique ID. This commit only renames circuit's unique ID to "circ_uniq_id". Signed-off-by: David Goulet

proto: Log both UniqId and CircId when possible

2026-08-03T18:27:50Z

This commit only affects logging. Whenever possible, log both the UniqId and CircId. This also changes the log lines which is now "uniq_id=" and "circ_id=" as the UniqId is internal and circ_id (CircId) is protocol level. Signed-off-by: David Goulet

proto: Rename CircId and UniqId variable name

2026-08-03T18:25:23Z

A CircId is now a circ_id and a UniqId is a unique_id so we stop confusing them in the code. Furthermore, channel_id that are CircId are now circ_id. Channel IDs are different and encoded internally into a UniqId. This is the first step to clarify semantic before we change the logging to log both unique ID and circ ID. No behavior change. Signed-off-by: David Goulet

proto: Include the actual cell command in an error message

2026-07-23T16:59:55Z

This can happen if we get an unexpected BEGIN_DIR/RESOLVE too, so we can't hard-code "BEGIN" in the error message. Context: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4230#note_3439258,

proto: Remove feature-gating from CircHop::handle_msg()

2026-07-23T16:59:55Z

This feature-gating has been a source of confusion, and it unnecessarily complicates the stream message handling flow. I've previously argued in favour of keeping it, in the spirit of a belt and braces approach to message validation, but I've been convinced that in this particular case, the feature-gate is more trouble than it's worth. What makes things worse is that the `CircHop::handle_msg()` function was designed poorly (by yours truly). I plan on refactoring it at some point, hopefully soon. There is a TODO about this below its doc comment.

proto: Add TODO about the eventual client-side reactor rewrite

2026-07-02T09:52:30Z

See https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4188#note_3432579

proto: Allow BeginDir and Resolve messages in the stream reactor (fmt)

2026-07-01T11:11:08Z