Access log tests are not useful when running tests concurrently #1084
Comments
howardjohn
added a commit
to howardjohn/ztunnel
that referenced
this issue
May 22, 2024
We were using the `cfg` in pool since istio#1040. `cfg` is not whether its used, but rather the intent of the user -- we may enable or disable at runtime. This renames the field to make it clear it should not be used like this, and fixes the issue. This went through CI due to istio#1084.
|
Can we just use |
|
We could, although that also leaves the inverse possible broken test (only works when not run concurrently)... either way we lose. Using nextest is good for other reasons though, probably a decent choice. We will need to add to build tools though |
Fine with that tradeoff, as those sorts of tests would almost assuredly show up as flakes in concurrent runs anyway. |
istio-testing
pushed a commit
that referenced
this issue
May 28, 2024
* Fix regression in source IP spoofing We were using the `cfg` in pool since #1040. `cfg` is not whether its used, but rather the intent of the user -- we may enable or disable at runtime. This renames the field to make it clear it should not be used like this, and fixes the issue. This went through CI due to #1084. * cleanup
|
We should be able to use |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
ztunnel/tests/namespaced.rs
Line 995 in 80ac30e
rust runs tests concurrently by default. We may get false-positives by matching other tests logs instead of our tests.
--test-threads 1orcargo-nextestcan weed these out, but it would be nice to somehow have per-test log collection. Note sure how though.FWIW I always use
cargo-nextestso as long as I am running tests locally we will find these issues quickly. However, that is a terrible long term stance 🙂The text was updated successfully, but these errors were encountered: