Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integration tests for redaction failing #1069

Open
gnunicorn opened this issue Sep 28, 2022 · 5 comments
Open

Integration tests for redaction failing #1069

gnunicorn opened this issue Sep 28, 2022 · 5 comments

Comments

@gnunicorn
Copy link
Contributor

since 1a57170 the redaction integration tests fail - name_static almost every time on CI, the other has been observed outside of CI to fail, too:

test tests::redaction::test_redacting_name_static ... FAILED
test tests::redaction::test_redacting_name ... ok

failures:

---- tests::redaction::test_redacting_name stdout ----
thread 'tests::redaction::test_redacting_name' panicked at 'dispatch dropped without returning error', /home/ben/.cargo/registry/src/jackfan.us.kg-1ecc6299db9ec823/hyper-0.14.20/src/client/conn.rs:329:35
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    tests::redaction::test_redacting_name

test result: FAILED. 2 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 5.61s
@jplatte
Copy link
Collaborator

jplatte commented Sep 29, 2022

This seems like an issue other people are facing too with hyper. Are we sharing the hyper client between multiple async runtimes perhaps? That's one way to trigger the error according to issues. These two seem to contain the most info:

@gnunicorn
Copy link
Contributor Author

gnunicorn commented Oct 7, 2022

multiple async runtimes perhaps?

does #[tokio::test] create a fresh runtime for every test? It would make sense, that it does. And then, yes. Our integration tests reuse existing clients stored in a dashmap static USERS: Lazy<Mutex<HashMap<String, (Client, TempDir)>>>.

@jplatte
Copy link
Collaborator

jplatte commented Oct 7, 2022

Yes, that is what #[tokio::test] does. Do we really need to reuse clients across tests, are they that expensive to create?

@gnunicorn
Copy link
Contributor Author

gnunicorn commented Oct 7, 2022

I think the main problem here is e2ee, so they are created for the entire test suite with the proper sled store in tmp (which he hold the tmpdir for so that it doesn't get scraped on drop), the other that we register with the server if they don't exist before (locally) - which saves a few roundtrips, too. I suppose we could change that. Maybe it does make sense to provide some TestClient that we can just hammer in some info (like the homeserver) to prevent the unnecessary roundtrips?

@jplatte
Copy link
Collaborator

jplatte commented Oct 7, 2022

The other option would be to not use #[tokio::test], and share the runtime across tests as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants