Piotr Kufel

Getting it to work for "fun" and having it working in a production system are two different things. If you're after the latter - it's not supported so whatever you...

Is this using some custom version of goimports? I recently had it complain about one import even though the file was formatted by goimports. Turned out it wanted me to...

I have ran into it a number of times and I'm quite surprised there's so little demand to fix it.. But yes, it seems to be the oauth library that...

Few observations: - The message above also claims SIGSEGV - Removing the offending unreachable! still causes SIGSEGV - It's not clear to me SIGSEGV actually happens vs the benchmark runner...

Unfortunately, reproduced in integration tests without the benchmark: ``` #[test] pub fn throughput() { let (env, rt) = initialize_environment(Mode::Read); let size = 10; rt.block_on(async { tcp::run_client(&mut env.lock().await.direct, size, Mode::Write).await }).unwrap();...

Sleeping 1 second after `block_on` fixes the issue. I think I know what's happening (but it's a **theory**, I don't know the test app code well enough): - initialize_environment creates...

> Perhaps SecretManager could be adjusted But problem is the opposite - it's not SecretManager going out of scope too early, it's the worker dying while there are SecretManager references...

As mentioned in my [previous](https://github.com/istio/ztunnel/issues/488#issuecomment-1501057441) comment, sleeping **after** the the test (but before drop/return) helps, so that's one form of semi-verification. Explicitly dropping env first doesn't help, but neither it...

> cleanup ordering in tests/benches From what I have seen, the main offender is actually app.rs. So you may see it in real world use too.

+1 for Guake; not sure how to reproduce, but once it happens it keeps happening till I restart nu - and it usually starts happening fairly quickly. Seems to have...