mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.2.0 2024-02-27T17:01:33Z 2024-02-27T17:01:33Z Gabriela Moldovan gabi@torproject.org 2024-02-27T13:52:10Z urn:sha1:e03371e7933deed293044d3e6b256dda88f5ba62 `tor_circmgr::Error::Protocol` will soon include an optional `UniqId`. Since `Protocol` errors can be caused by pending circuits, we need to be able to peek at their `UniqId`. Part of #1297 2024-02-27T16:57:25Z Gabriela Moldovan gabi@torproject.org 2024-02-27T15:06:48Z urn:sha1:62923a6758be629b684d67237f7d7207abad33f0 Some of the `tor_circmgr::Error` variants will include the `UniqId` of the corresponding circuit, so we'll need to be able to display it without the `Circ ` prefix. Part of #1297 2024-02-13T14:37:11Z Nick Mathewson nickm@torproject.org 2024-02-13T14:37:11Z urn:sha1:b5c70dad02124549a13e25f62c8073fef4a063fe We never actually constructed these before, but now we enforce it at the API level. Part of #1269. 2024-01-17T18:27:09Z gabi-250 gabi@torproject.org 2024-01-17T18:27:09Z urn:sha1:572078cd57fc3a916d7d4cc9a2ad3dfcd2d13fd8 Several clean-ups around failures in incoming stream request handlers. Closes #1190, #1189, and #1188 See merge request tpo/core/arti!1892 2024-01-17T16:19:54Z Nick Mathewson nickm@torproject.org 2024-01-17T16:19:54Z urn:sha1:25258bfc1061429f99a62426d41824be29d46df1 The bug described here was already fixed as #1065 via !1681. Closes #1191. 2024-01-17T14:25:56Z Nick Mathewson nickm@torproject.org 2024-01-17T14:25:56Z urn:sha1:c5478deab5b8bb4a1ea55946483bad948ff9eca0 2024-01-17T14:00:34Z Nick Mathewson nickm@torproject.org 2024-01-17T14:00:34Z urn:sha1:8bff4734d70bc1260cfd5fdfb230e479b79065fc Closes #1190 2024-01-17T13:45:54Z Nick Mathewson nickm@torproject.org 2024-01-17T13:45:54Z urn:sha1:163aec238f5cba8434826130d5637f6ae3a24a4b In theory, it might be better to just un-register the IncomingStreamRequestHandler when the Receiver for the stream requests is dropped. However, there are two reasons not to do so: 1. It's tricky. We never actually poll on the corresponding Sink, so there isn't a place where the Reactor would expect to get a prompt notification of closure. We only find out that the Receiver has been dropped when an attempt to send on the Sink returns an `is_disconnected` error. 2. It's unnecessary. In the Tor protocols, once we have decided to accept incoming stream requests on a circuit, we want to continue to do so until one of the parties closes the circuit. I've documented this in several comments, in case whe want to get fancier in the future. Closes #1188. 2024-01-17T13:16:48Z Nick Mathewson nickm@torproject.org 2024-01-17T13:16:48Z urn:sha1:428285a3b9df515e25a4b4265950b3a0fc788430 Closes #1189. 2024-01-10T15:04:27Z Nick Mathewson nickm@torproject.org 2024-01-10T15:04:27Z urn:sha1:ca44209c77d2c1267c3fe9e5a0fa707e88e5868b