c5ee3250f7
* refactor: remove line number from test
* refactor: clean up code
* fix: flaky `service::tests::test_log_on_panic`
This seems to be a really rare issue. So provoking it requires a lot of
tests. This can be done (using `fish`):
```console
$ while cargo with "parallel -n0 {bin} {args} ::: $(seq 10)" -- test -p service_grpc_influxrpc --lib -- --test-threads 20; echo; end
```
Fixes #7838.
* fix: panic handler construction
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
|
||
|---|---|---|
| .. | ||
| src | ||
| .gitattributes | ||
| Cargo.toml | ||
| README.md | ||
| build.rs | ||
README.md
workspace-hack
This crate is a "workspace hack" crate managed by cargo hakari.
Its purpose is to unify the features used by all crates in the workspace so that the crates share more dependencies and rebuild crates less. There are more details in hakari's documentation.
CI failures
If the workspace_hack_checks CI job is failing, there are two possible reasons and solutions:
- If
cargo hakari generate --difffails, that means a crate has started or stopped using a feature of some crate and that feature isn't up-to-date in theworkspace-hackcrate. To fix this, runcargo hakari generateand commit the changes. - If
cargo hakari manage-deps --dry-runfails, that means a crate in the workspace isn't depending on theworkspace-hackcrate. To fix this, runcargo hakari manage-depsand commit the changes.