mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.9.0 2025-08-07T15:28:36Z 2025-08-07T15:28:36Z Nick Mathewson nickm@torproject.org 2025-08-06T01:19:58Z urn:sha1:77b0de43b8c67cdb81befe0680a3df43b6ad37bc First, run ``` git grep -l "^edition =" | xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;' ``` Second, manually verify that all Cargo.toml files have changed, and nothing else has changed. Third, run cargo fmt again. 2025-01-15T19:05:30Z Nick Mathewson nickm@torproject.org 2025-01-15T19:03:31Z urn:sha1:71260de3ce35186a6e68fc10f0cae409258b4f80 Closes #1500. 2024-10-17T23:16:58Z Nick Mathewson nickm@torproject.org 2024-10-16T18:58:58Z urn:sha1:5219f4cee5a74c0abdd8ad548b4ead9e2066cb2c These are not regular ErrorKinds, since they can never occur in an error that's meant to be returned from a Rust API like `arti-client`. Instead, they only exist for errors returned from RpcError. (I can't find the place where we discussed this previously, but the rationale is that if an ErrorKind never makes sense in response to something that the user does from Rust, we should never have that be an ErrorKind. The fact that the removed kinds do not actually appear outside the RPC system suggests that this is reasonable.) 2024-09-16T17:17:14Z Nick Mathewson nickm@torproject.org 2024-09-12T15:54:47Z urn: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. 2024-09-16T17:17:14Z Nick Mathewson nickm@torproject.org 2024-09-09T19:38:39Z urn: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. 2024-07-25T12:46:29Z Nick Mathewson nickm@torproject.org 2024-07-24T18:51:54Z urn:sha1:847e80f307789c607ac3415254b292e20da9c7f0 2023-04-19T16:38:26Z Nick Mathewson nickm@torproject.org 2023-04-18T22:43:16Z urn:sha1:accd3d858f9812eba326306014a9543590d93dad Right now, this lets us say whether the method was unrecognized or whether the parameter type was incorrect. We'll use this to enforce correct method names later on. (I have to add another `inventory` here, since the `typetag` maintainer does not want to expose this functionality: see https://github.com/dtolnay/typetag/issues/57#issuecomment-1506106290 ) 2023-04-12T20:21:34Z Nick Mathewson nickm@torproject.org 2023-04-12T19:59:47Z urn:sha1:767c91557e6b6bc5429f30b886f8a314df2ddf22 This is a bit big, but it's not that _complicated_. The idea here is that we use serde's "untagged" enum facility when parsing our `Request`s, such that if parsing as a `Request` fails, we parse as an `InvalidRequest` and try to report what the problem was exactly. This lets us determine the ID of a request (if it had one), so we can report that ID in our error message. We can also recover from a much broader variety of errors. We now also conform with the spec reporting errors about completely wrong json, requests without IDs, and so on.