mirrors/arti.git/crates/arti-rpcserver/src, branch arti-v1.2.8mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.2.82024-09-24T14:23:53Zrpc: Rename SingletonId to SingleIdResponse2024-09-24T14:23:53ZNick Mathewsonnickm@torproject.org2024-09-24T14:21:17Zurn:sha1:bd9b29b05de6c133b93366acb69d9e2ce6b126cd
Calling it "singleton" might have suggested that it was using the
[singleton pattern](https://en.wikipedia.org/wiki/Singleton_pattern),
which it isn't.
(Renaming done with rust-analyzer and double-checked with `git grep`.)
Closes #1585.
rpcserver: Split a few long lines.2024-09-16T17:17:14ZNick Mathewsonnickm@torproject.org2024-09-16T17:15:50Zurn:sha1:b70f652ef40c0c3475c9e1c2ad9e529f320e8ecerpcserver: move is_connection_close detection into run_loop.2024-09-16T17:17:14ZNick Mathewsonnickm@torproject.org2024-09-16T15:39:44Zurn:sha1:ababd02a198fbc3cc95320cbfa58c404fd4eee38
I've used an `async{ expr }.await` pattern, to make sure that
_every_ error returned by the `loop{select!{}}` construct is
actually transformed.
rpcserver: Add an extra level of braces.2024-09-16T17:17:14ZNick Mathewsonnickm@torproject.org2024-09-16T15:35:35Zurn:sha1:f296e4d8e872f62c99c2a09c79c9fa803dcafc7f
(This will make the next commit easier to read.)
rpcserver: Apply documentation suggestion.2024-09-16T17:17:14ZNick Mathewsonnickm@torproject.org2024-09-16T15:28:55Zurn:sha1:5d2c1592c6f31bff285f2823fda37a0bdff83601rpcserver: Use a struct to enforce explicit Continue2024-09-16T17:17:14ZNick Mathewsonnickm@torproject.org2024-09-16T15:26:44Zurn:sha1:b49019625e56aac3cde5f99016ce4f5eb28043fb
Per suggestion from @diziet.
rpc: Simplify simplified close logic even further2024-09-16T17:17:14ZNick Mathewsonnickm@torproject.org2024-09-12T15:54:47Zurn:sha1:2bc973743da29b16f3e813521e7cef1015e762d4
Instead of classifying errors and complicating our behavior _early_
in our loop, instead we just decide whether an error indicates an
EOF immediately before we return it.
rpc: Simplify close logic even further.2024-09-16T17:17:14ZNick Mathewsonnickm@torproject.org2024-09-09T19:45:09Zurn:sha1:41779bf225342d1cb07b58bba094c6109d9c6377
Make it more clear than the previous match statement
that once we get an Err() from request_stream.next(),
we aren't going to continue the loop.
rpc: Simplify handling of fatal Json read errors.2024-09-16T17:17:14ZNick Mathewsonnickm@torproject.org2024-09-09T19:38:39Zurn:sha1:c13eaaea7fb939bebe13637536e146357267eb62
Previously, after determining that an error on an RPC connection
was fatal, we would:
1. Determine whether it was a "clean" close or one
that needed to be logged.
2. In exactly one case (specifically, when the inbound Json stream
contained a Value that was not an Object) , we would send back a
message to the client.
3. Exit the connection with Ok() or Err(e).
We no longer do step "2" above.
Additionally, we document:
- Why it's important to exit immediately on syntax errors.
- A better way to tolerate non-Object Json Values,
if we decide someday to do so.
Closes #1591.
rpc: More specificity surrounding SOCKS-rpc integration2024-09-09T14:52:56ZNick Mathewsonnickm@torproject.org2024-09-04T17:39:51Zurn:sha1:56bd675297f2302cf805677259139f90f6b6736a