-
Notifications
You must be signed in to change notification settings - Fork 2.1k
perf: Faster integration tests for add_documents.rs #5574
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
perf: Faster integration tests for add_documents.rs #5574
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @martin-g thanks for your interest in this issue!
This file was one of the tricky one sorry, a lot of the tests at the beginning don't look like the usual Meilisearch test and were not really described in my issue 😬
I left a lot of comments here and there, hope that helps. I also noticed that a you skipped a lot of tests where we could have used a shared instance + unique index.
Try searching for the Server::new
.
The only case where we can't use a shared server is when the test is modifying a global part of the instance, like a specific test on the task queue, the api keys or the experimental features.
Here I believe you should be all good!
Also, the the file is fairly big. That was not part of the issue but if you want feel free to split it into 3 smaller files (or more if you find good names for each files).
We're trying to help rust analyzer run on our tests by never having file with more than 1000 lines of code.
Thanks again for your contribution!
// this is what is expected and should work | ||
let server = Server::new_shared(); | ||
let app = server.init_web_app().await; | ||
|
||
// post |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The shared server is nice but afterward we're hardcoding the name of the index to be dog.
This could be flaky in the future, instead we should create a new unique index.
Also, when we snapshoted the task, we can see it has the task id 0 which is definirely flaky.
We should just call snapshot!(response, ...);
without the json_string to properly snapshot the tasks
// wait first batch of documents to finish | ||
futures::future::join_all(waiter).await; | ||
index.wait_task(4).await; | ||
index.wait_task(4).await.succeeded(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here it would also be better to share the Server and get a unique index but it also means we cannot wait for the task 4 anymore.
We now have to store and retrieve the task id of the last task in the join and wait for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, we still have this issue. We cannot wait for any task with an hardcoded number as they will change between run on a shared server 😔
@@ -2925,7 +2925,7 @@ async fn batch_several_documents_addition() { | |||
} | |||
// wait second batch of documents to finish | |||
futures::future::join_all(waiter).await; | |||
index.wait_task(9).await; | |||
index.wait_task(9).await.failed(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above
Thank you for the review, @irevoire ! |
@irevoire This is ready for a new review! |
0c5f85a
to
79e33d1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey!
Same as your other PR, we're almost good and only one last test is flaky because we're waiting for a task with an hardcoded task id.
Then we're good to merge 🚀
// wait first batch of documents to finish | ||
futures::future::join_all(waiter).await; | ||
index.wait_task(4).await; | ||
index.wait_task(4).await.succeeded(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, we still have this issue. We cannot wait for any task with an hardcoded number as they will change between run on a shared server 😔
@irevoire Could you please take a look at https://github.com/meilisearch/meilisearch/actions/runs/15276592157/job/42964417626?pr=5574 ? The test name is let server = Server::new().await;
let index = server.index("test"); This creates an index, no ? The new code is: let server = Server::new_shared();
let index = server.unique_index(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, I found your bug and quickly looked if I could find more. I think we'll be good once you fix this one
Use Shared server where possible Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org>
Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org>
Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org>
Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org>
Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org>
Some of them succeed, others fail. Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org>
Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org>
Co-authored-by: Tamo <irevoire@protonmail.ch>
Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org>
Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org>
ddb61ad
to
02929e2
Compare
Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you it's really awesome that you solved the anonymous index name!
Pull Request
Related issue
#4840
What does this PR do?
PR checklist
Please check if your PR fulfills the following requirements:
Thank you so much for contributing to Meilisearch!