tonic-side-effect
| Crates.io | tonic-side-effect |
| lib.rs | tonic-side-effect |
| version | |
| source | src |
| created_at | 2024-12-09 20:00:57.033196 |
| updated_at | 2024-12-09 20:00:57.033196 |
| description | Tower service that can monitor if a Tonic request frame was produced prior to error. |
| homepage | https://github.com/s2-streamstore/tonic-side-effect |
| repository | https://github.com/s2-streamstore/tonic-side-effect |
| max_upload_size | |
| id | 1477752 |
| Cargo.toml error: | TOML parse error at line 17, column 1 | 17 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
| size | 0 |
dev (github:s2-streamstore:dev)
documentation
README
tonic-side-effect
This crate provides a tower service for wrapping a tonic Channel, which monitors if a request Body ever produced a frame before returning an error.
The service communicates whether poll_frame on the request ever produced data, via a handle to shared state.
Why might this be helpful?
It can be useful, when building systems that need to carefully consider potential side-effects from RPCs, to disambiguate between failures which occurred strictly before any data from a request could possibly have been read (as might be the case for a connection refused or DNS error), and failures which occurred after request data may have been consumed (e.g. a connection reset).
A tonic Status represents the mapping of many types of underlying failures into gRPC status, and it's not possible to make hard guarantees about whether any request content was transmitted or not simply by considering the status code.
This service provides more direct access to a boundary that is of particular interest for purposes of reasoning about RPC side-effects (and in a safer way than rooting around in the status' error source chain).