mirrors/arti.git/crates/arti-rpcserver/src/connection.rs, 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-16T17:17:14Zrpcserver: 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.
rpcserver: use more sophisticated handling for ConnectionError.2024-08-13T01:27:50ZNick Mathewsonnickm@torproject.org2024-08-13T01:27:50Zurn:sha1:4e0c62da453dec6bacae586d4dac940beff61e94
In general, we don't want to return a ConnectionError for a simple
EOF condition; we only want to report an error when there's an
actual failure.
Also, it's a good idea to capture the actual error return conditions
that we get from aynchronous_codecs, rather than throwing them away
as we did before.
Closes #1517.
Implement rpc::Context on Connection directly2024-06-10T14:33:01ZNick Mathewsonnickm@torproject.org2024-06-05T14:00:25Zurn:sha1:aaf12c8970e35ff0f9873cf4c2e27adb2ccaf9e5
This lets us get rid of a now-spurious `RequestContext` wrapper type
and an extra layer of indirection; it will also make it easier to
treat a Connection _as_ a context, so that we can have a context in
the socks-rpc interface code.
This patch removes a TODO about "treading carefully" when we make
this change. When I added that TODO, I had misremembered some
implementation details of the RPC object system.