summaryrefslogtreecommitdiff
path: root/crates/arti-rpcserver
Commit message (Collapse)AuthorAgeFilesLines
* Bump versions of internal arti crates for Arti 1.3.2Nick Mathewson2025-01-071-10/+10
| | | | | | | | | | | | | The affected crates follow our regular versioning. They all get bumped to 0.26.0. Done with ``` for crate in $(./maint/list_crates |grep '^arti-\|tor-' ); do cargo set-version --bump minor -p $crate; done ```
* clippy: deny `mod_module_files`Steven Engler2025-01-061-0/+1
| | | | | | Denies 'mod.rs' files for consistency. https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
* add_warnings, *: Allow clippy::needless_lifetimesNick Mathewson2024-12-031-0/+1
| | | | | | | | In 1.83, this warning triggers on many of our crates. We're thinking of fixing them all, but for now, we're going to disable the warning. This is part of #1765.
* Bump all the unstable tor- and arti- crates to 0.25.0.Gabriela Moldovan2024-12-021-10/+10
| | | | | | | | | | Done using: ``` for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do cargo set-version -p $crate 0.25.0 done ```
* Bump the versions of the non-{arti-,tor-} crates.Gabriela Moldovan2024-12-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The non-{arti-,tor-} crates are: ``` ./maint/list_crates | rg -v '^(tor|arti)' oneshot-fused-workaround slotmap-careful test-temp-dir fslock-guard hashx equix caret fs-mistrust safelog retry-error ``` We split them in the following categories: * crates with no changes (no version bumps): ``` maint/changed_crates -v "arti-v$LAST_VERSION" 2>&1 >/dev/null | grep -i "no change" | grep -v '\(tor\|arti\)-' oneshot-fused-workaround: No change. test-temp-dir: No change. caret: No change. ``` * crates that only have non-functional changes (bump the patch version): - slotmap-careful - fslock-guard - hashx - equix - fs-mistrust - safelog - retry-error * crates where APIs were broken (bump minor): None The bumps from this commit were created using this script: ``` PATCH=" slotmap-careful fslock-guard hashx equix fs-mistrust safelog retry-error " for crate in $PATCH; do cargo set-version --bump patch -p $crate; done ```
* cargo: Update `thiserror` to `2`Clara Engler2024-11-121-1/+1
|
* Bump minor versions of crates with new APIs/implsIan Jackson2024-10-301-1/+1
| | | | | cargo set-version --bump=patch -p slotmap-careful cargo set-version --bump=patch -p safelog
* Bump unstable tor-* and arti-* crates to 0.24.0Ian Jackson2024-10-301-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cargo set-version -p tor-async-utils 0.24.0 cargo set-version -p tor-basic-utils 0.24.0 cargo set-version -p tor-bytes 0.24.0 cargo set-version -p tor-cell 0.24.0 cargo set-version -p tor-cert 0.24.0 cargo set-version -p tor-chanmgr 0.24.0 cargo set-version -p tor-checkable 0.24.0 cargo set-version -p tor-circmgr 0.24.0 cargo set-version -p tor-config 0.24.0 cargo set-version -p tor-config-path 0.24.0 cargo set-version -p tor-consdiff 0.24.0 cargo set-version -p tor-dirclient 0.24.0 cargo set-version -p tor-dirmgr 0.24.0 cargo set-version -p tor-error 0.24.0 cargo set-version -p tor-general-addr 0.24.0 cargo set-version -p tor-geoip 0.24.0 cargo set-version -p tor-guardmgr 0.24.0 cargo set-version -p tor-hsclient 0.24.0 cargo set-version -p tor-hscrypto 0.24.0 cargo set-version -p tor-hsrproxy 0.24.0 cargo set-version -p tor-hsservice 0.24.0 cargo set-version -p tor-key-forge 0.24.0 cargo set-version -p tor-keymgr 0.24.0 cargo set-version -p tor-linkspec 0.24.0 cargo set-version -p tor-llcrypto 0.24.0 cargo set-version -p tor-log-ratelim 0.24.0 cargo set-version -p tor-memquota 0.24.0 cargo set-version -p tor-netdir 0.24.0 cargo set-version -p tor-netdoc 0.24.0 cargo set-version -p tor-persist 0.24.0 cargo set-version -p tor-proto 0.24.0 cargo set-version -p tor-protover 0.24.0 cargo set-version -p tor-ptmgr 0.24.0 cargo set-version -p tor-relay-crypto 0.24.0 cargo set-version -p tor-relay-selection 0.24.0 cargo set-version -p tor-rpcbase 0.24.0 cargo set-version -p tor-rtcompat 0.24.0 cargo set-version -p tor-rtmock 0.24.0 cargo set-version -p tor-socksproto 0.24.0 cargo set-version -p tor-units 0.24.0 cargo set-version -p arti-client 0.24.0 cargo set-version -p arti-relay 0.24.0 cargo set-version -p arti-rpc-client-core 0.24.0 cargo set-version -p arti-rpcserver 0.24.0
* Remove echo structsNeel Chauhan2024-10-251-14/+0
|
* arti-rpcserver: Remove echo_on_sessionNeel Chauhan2024-10-251-12/+0
|
* rpc: Tweak release_owned to give an error on second removal of "connection".Nick Mathewson2024-10-231-16/+20
|
* rpc: Use a const for the "connection" object ID.Nick Mathewson2024-10-231-2/+9
|
* rpc: Simplify method-dispatch-bypass logic a bitNick Mathewson2024-10-232-9/+2
| | | | | | | | | | | | | | | This commit removes the separate function for asking whether to bypass the dispatch code. Instead, it gives the "invoke with bypass" function an error to return when no dispatch is warranted, and moves the whole responsibility for method dispatch or non-dispatch back into tor-rpcbase. I had to add an ObjectId argument to `invoke_rpc_method` to make this work, but that's probably a good thing. Additionally, this commit tweaks the derive-deftly macro to prevent you from asking for dispatch bypass on special methods, where it isn't implemented (and doesn't really make sense).
* rpc: Add support for dropping the special "connection" object ID.Nick Mathewson2024-10-231-9/+19
|
* rpc: Move "rpc:release" to be a method on the rpc object.Nick Mathewson2024-10-231-24/+24
| | | | | | | Now, instead of telling the session or the connection to drop the object ID, we tell the object ID to go away. Closes #1663.
* rpcserver: detect and use methods that bypass method dispatch.Nick Mathewson2024-10-231-3/+8
|
* rpc: Remove unimplemented rpc:downgrade method for now.Nick Mathewson2024-10-231-9/+0
| | | | | If and when we implement this, it will likely be different; arti#868 has some thoughts on the implications.
* rpc: Move some object-id-manipulation methods to a new module.Nick Mathewson2024-10-233-50/+63
| | | | | These will have different implementations soon; this is a more logical place for them.
* Merge branch 'arti-rpcserver-comment' into 'main'wesleyac2024-10-211-1/+1
|\ | | | | | | | | Fix typo in arti-rpcserver auth.rs comment See merge request tpo/core/arti!2558
| * Fix typo in arti-rpcserver auth.rs commentNeel Chauhan2024-10-181-1/+1
| |
* | rpc: List missing required features in error dataNick Mathewson2024-10-171-5/+7
| | | | | | | | | | | | | | | | | | | | Our spec says that when the RPC client has said "I require you to have feature X" and we don't have it, we need to include the feature(s) we don't have in an `rpc:unsupported_features` field of our error. Also, add an integration test for this behavior. Closes #1662
* | Remove Rpc* variants from tor_error::ErrorKindNick Mathewson2024-10-173-21/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.)
* | rpcserver: Wrap InvokeError as internal errorNick Mathewson2024-10-172-6/+8
|/ | | | | | | | | I'm about to remove HasKind from InvokeError, which would otherwise break this code. These errors are all in fact internal errors, since in this context they can only stem from incorrectly formed calls to `invoke_special_method`.
* Merge branch 'mq-prevent' into 'main'Ian Jackson2024-10-151-2/+5
|\ | | | | | | | | | | | | Use clippy to prevent non-mq use of mpsc::channel Closes #1659 See merge request tpo/core/arti!2536
| * Use mpsc_channel_no_memquota in the RPC system (adding a TODO)Ian Jackson2024-10-151-2/+5
| | | | | | | | | | We need to decide whether RPC will participate in memquota. Perhaps it should. But that's for the future.
* | Replace _ => panic!() elsewhereIan Jackson2024-10-151-1/+1
|/
* arti-rpcserver: minimal handling for request.meta.requireNick Mathewson2024-10-072-2/+30
| | | | | | | | | | We have defined a forward-compatibility mechanism for the RPC system, where a request may list one or more required "features", and if any feature is absent, the request will fail. Since no "features" are currently implemented, this code does the bare minimum to implement this mechanism, by rejecting every request with a nonempty "require" field.
* arti-rpcserver: Correctly handle rpc.meta without `updates`Nick Mathewson2024-10-071-0/+1
| | | | | The `update` field in request.meta is optional, so we should allow it to default to `false` when it is absent.
* rpcserver: Remove TODO about optionality of paramsNick Mathewson2024-10-071-3/+0
| | | | | | | The spec no longer says that `params` is optional, so we can remove the TODO about making it optional. Closes #1665.
* rpc: clarify documentation and fix typosNick Mathewson2024-10-022-3/+6
| | | | Based on review from @opara.
* Revise RPC documentation to be more informative.Nick Mathewson2024-10-024-13/+73
| | | | | | Previous documentation was more-or-less meant for the Arti developer only. This new documentation is intended for actual users of RPC functionality. It's meant to be extracted with `maint/rpc-doc-tool`.
* Bump arti- and tor- crates to 0.23.0Nick Mathewson2024-09-301-10/+10
| | | | | | | | | | | | | | Per our policy, every one of these gets a minor bump. Generated with: ``` for crate in $(./maint/list_crates | grep '^\(tor\|arti\)-' ); do cargo set-version --bump minor -p $crate; done ``` (Note the use of `-` at the end end of the grep pattern to prevent matching the `arti` crate.)
* Minor bumps on non-tor/arti cratesNick Mathewson2024-09-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These crates are not in the tor/arti namespace, but we have given them MSRV bumps: ``` oneshot-fused-workaround slotmap-careful fslock-guard hashx equix caret fs-mistrust safelog test-temp-dir retry-error ``` We are counting this as a breaking change. Since all of these crates are at 0.x.x, we have indicated the breaking change with a minor version bump. This commit was generated with the following script: ``` BUMPS=" oneshot-fused-workaround slotmap-careful fslock-guard hashx equix caret fs-mistrust safelog test-temp-dir retry-error " for crate in $BUMPS; do cargo set-version --bump minor -p $crate; done ```
* Merge branch 'msrv-1.77-and-rusqlite-update' into 'main'David Goulet2024-09-261-1/+1
|\ | | | | | | | | Upgrade MSRV to 1.77 , and rusqlite to 0.32.1 See merge request tpo/core/arti!2451
| * Upgrade MSRV to 1.77Nick Mathewson2024-09-251-1/+1
| | | | | | | | This will allow us to upgrade to the latest version of rusqlite.
* | Merge branch 'upgrades-20240925' into 'main'Nick Mathewson2024-09-261-1/+1
|\ \ | |/ |/| | | | | Upgrade dependencies in preparation for next week's releases. See merge request tpo/core/arti!2450
| * Upgrade to derive_more version 1.0.0Nick Mathewson2024-09-251-1/+1
| | | | | | | | | | | | The `derive_more` crate broke backward compatibility with this version, so this change involved quite a few manual fixups. With luck, they'll keep compatibility for some while in the future.
* | rpc: Rename SingletonId to SingleIdResponseNick Mathewson2024-09-242-8/+8
|/ | | | | | | | | | 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.
* Bump MSRV from 1.70 to 1.75.Wesley Aptekar-Cassels2024-09-161-1/+1
|
* rpcserver: Split a few long lines.Nick Mathewson2024-09-161-5/+10
|
* rpcserver: move is_connection_close detection into run_loop.Nick Mathewson2024-09-161-6/+10
| | | | | | 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.Nick Mathewson2024-09-161-50/+52
| | | | (This will make the next commit easier to read.)
* rpcserver: Apply documentation suggestion.Nick Mathewson2024-09-161-0/+2
|
* rpcserver: Use a struct to enforce explicit ContinueNick Mathewson2024-09-161-2/+10
| | | | Per suggestion from @diziet.
* rpc: Simplify simplified close logic even furtherNick Mathewson2024-09-162-35/+38
| | | | | | 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.Nick Mathewson2024-09-161-6/+4
| | | | | | 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.Nick Mathewson2024-09-163-44/+33
| | | | | | | | | | | | | | | | | | | | 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 integrationNick Mathewson2024-09-091-1/+8
|
* Bump all the unstable tor- and arti- crates to 0.22.0.Gabriela Moldovan2024-09-031-10/+10
| | | | | | | | | | Done using: ``` for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do cargo set-version -p $crate 0.22.0 done ```
* oneshot-fused-workaround: Set the initial version to 0.1.0.Gabriela Moldovan2024-09-031-1/+1
| | | | This is the first time we're publishing this, so let's start at 0.1.0.