Skip to content

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

Merged
merged 11 commits into from
May 28, 2025

Conversation

martin-g
Copy link
Contributor

Pull Request

Related issue

#4840

What does this PR do?

PR checklist

Please check if your PR fulfills the following requirements:

  • Does this PR fix an existing issue, or have you listed the changes applied in the PR description (and why they are needed)?
  • Have you read the contributing guidelines?
  • Have you made sure that the title is accurate and descriptive of the changes?

Thank you so much for contributing to Meilisearch!

Copy link
Member

@irevoire irevoire left a 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!

Comment on lines 21 to 26
// this is what is expected and should work
let server = Server::new_shared();
let app = server.init_web_app().await;

// post
Copy link
Member

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

Comment on lines 2914 to 2916
// wait first batch of documents to finish
futures::future::join_all(waiter).await;
index.wait_task(4).await;
index.wait_task(4).await.succeeded();
Copy link
Member

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.

Copy link
Member

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();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above

@martin-g
Copy link
Contributor Author

Thank you for the review, @irevoire !
Let me better understand the testing mini-framework by working on smaller tests first! I will come back to this one later!

@martin-g martin-g marked this pull request as draft May 19, 2025 11:54
@martin-g martin-g marked this pull request as ready for review May 26, 2025 08:32
@martin-g
Copy link
Contributor Author

@irevoire This is ready for a new review!
I didn't split the file into several ones because it will make the review harder.

@martin-g martin-g force-pushed the faster-add_documents-it-tests branch 2 times, most recently from 0c5f85a to 79e33d1 Compare May 26, 2025 08:36
Copy link
Member

@irevoire irevoire left a 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 🚀

Comment on lines 2914 to 2916
// wait first batch of documents to finish
futures::future::join_all(waiter).await;
index.wait_task(4).await;
index.wait_task(4).await.succeeded();
Copy link
Member

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 😔

@martin-g
Copy link
Contributor Author

@irevoire Could you please take a look at https://github.com/meilisearch/meilisearch/actions/runs/15276592157/job/42964417626?pr=5574 ?
I do not understand why it the response now says that there were 2 received and indexed documents.

The test name is add_documents_no_index_creation but the old code was:

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();

Copy link
Member

@irevoire irevoire left a 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

martin-g and others added 10 commits May 28, 2025 14:18
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>
@martin-g martin-g force-pushed the faster-add_documents-it-tests branch from ddb61ad to 02929e2 Compare May 28, 2025 11:37
Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org>
@irevoire irevoire added this to the v1.16.0 milestone May 28, 2025
@irevoire irevoire added maintenance Issue about maintenance (CI, tests, refacto...) no db change The database didn't change labels May 28, 2025
Copy link
Member

@irevoire irevoire left a 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!

@irevoire irevoire added this pull request to the merge queue May 28, 2025
Merged via the queue into meilisearch:main with commit c8e77b5 May 28, 2025
12 of 16 checks passed
@martin-g martin-g deleted the faster-add_documents-it-tests branch May 29, 2025 05:07
@meili-bot meili-bot added the v1.16.0 PRs/issues solved in v1.16.0 released on 2025-08-04 label Aug 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maintenance Issue about maintenance (CI, tests, refacto...) no db change The database didn't change v1.16.0 PRs/issues solved in v1.16.0 released on 2025-08-04
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants