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

Improve HttpRequests #1741

Open
wants to merge 31 commits into
base: main
Choose a base branch
from
Open

Conversation

flevi29
Copy link
Collaborator

@flevi29 flevi29 commented Oct 9, 2024

Pull Request

Sorry for the huge PR, but HttpRequests is core, and is used everywhere.

What does this PR do?

Caution

BREAKING: From now on only some methods are public on HttpRequests (get, post, put, patch, delete), the rest of the properties and methods are internal implementation details, and are not meant to be directly accessed.

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

codecov bot commented Oct 9, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.44%. Comparing base (af27c78) to head (ed15092).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1741      +/-   ##
==========================================
+ Coverage   98.21%   98.44%   +0.23%     
==========================================
  Files          17       17              
  Lines        1565     1606      +41     
  Branches      333      343      +10     
==========================================
+ Hits         1537     1581      +44     
+ Misses         28       25       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@flevi29 flevi29 added maintenance Issue about maintenance (CI, tests, refacto...) breaking-change The related changes are breaking for the users and removed maintenance Issue about maintenance (CI, tests, refacto...) labels Oct 9, 2024
@flevi29 flevi29 linked an issue Oct 10, 2024 that may be closed by this pull request
body: params,
})) as EnqueuedTaskObject;

return new EnqueuedTask(taks);
}
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

bug: previously this did not return EnqueuedTask, but rather EnqueuedTaskObject

Comment on lines 72 to 95
test(`${permission} key: Create client with custom headers (object)`, async () => {
const key = await getKey(permission);
const client = new MeiliSearch({
...config,
apiKey: key,
requestInit: {
headers: {
"Hello-There!": "General Kenobi",
},
},
},
});

assert.isTrue(await client.isHealthy());

assert.isDefined(fetchSpy.mock.lastCall);
const [, requestInit] = fetchSpy.mock.lastCall!;

assert.isDefined(requestInit?.headers);
assert.instanceOf(requestInit!.headers, Headers);
assert.strictEqual(
(requestInit!.headers! as Headers).get("Hello-There!"),
"General Kenobi",
);
});
Copy link
Collaborator Author

@flevi29 flevi29 Oct 10, 2024

Choose a reason for hiding this comment

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

Because headers are internal implementation details, to check them we have to spy on fetch now.

src/indexes.ts Show resolved Hide resolved
src/indexes.ts Outdated
Comment on lines 565 to 571
async deleteDocument(documentId: string | number): Promise<EnqueuedTask> {
const url = `indexes/${this.uid}/documents/${documentId}`;
const task = await this.httpRequest.delete<EnqueuedTask>(url);

task.enqueuedAt = new Date(task.enqueuedAt);
const task = (await this.httpRequest.delete({
relativeURL: `indexes/${this.uid}/documents/${documentId}`,
})) as EnqueuedTaskObject;

return task;
return new EnqueuedTask(task);
}
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

bug: previously this did not return EnqueuedTask

src/indexes.ts Show resolved Hide resolved
src/indexes.ts Outdated
Comment on lines 669 to 676
async updateSettings(settings: Settings): Promise<EnqueuedTask> {
const url = `indexes/${this.uid}/settings`;
const task = await this.httpRequest.patch(url, settings);
const task = (await this.httpRequest.patch({
relativeURL: `indexes/${this.uid}/settings`,
body: settings,
})) as EnqueuedTaskObject;

task.enqueued = new Date(task.enqueuedAt);

return task;
return new EnqueuedTask(task);
}
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

bug: previously this did not return EnqueuedTask, I'm not going to mark the rest, there are more

src/indexes.ts Outdated Show resolved Hide resolved
@flevi29 flevi29 marked this pull request as ready for review October 11, 2024 08:37
@flevi29 flevi29 requested a review from brunoocasali October 11, 2024 11:00
@Barabasbalazs Barabasbalazs mentioned this pull request Oct 21, 2024
3 tasks
@flevi29 flevi29 added the bug Something isn't working label Dec 24, 2024
@Strift Strift added the maintenance Issue about maintenance (CI, tests, refacto...) label Jan 8, 2025
@flevi29 flevi29 requested a review from Strift January 8, 2025 13:35
Copy link
Collaborator

@Strift Strift left a comment

Choose a reason for hiding this comment

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

Hi @flevi29, thanks for the great work 🙌

I would love to merge this too before the new release!I have a few questions:

Generic methods types

Any reason to switch from method<Type>() to method() as Type?
One example is in indexes.ts: await this.httpRequest.get(...) as IndexObject;, but there are other occurrences of this.

The former approach seems to provide a better DX.

Renaming config to extraRequestInit

I'm all for renaming it in variables and types used internally to make the code base more self-explanatory. But I'm not sure about changing the user-facing field names.

I feel like config / requestConfig are more familiar field names for configuring the underlying HTTP client/request.

Plus, changing them would be a breaking change, right?

src/indexes.ts Show resolved Hide resolved
@@ -1435,10 +1437,66 @@ describe.each([
try {
await client.health();
} catch (e: any) {
expect(e.cause.message).toEqual("Error: Request Timed Out");
expect(e.cause.message).toEqual("request timed out after 1ms");
Copy link
Collaborator

Choose a reason for hiding this comment

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

Let's keep it closer to the original formatting:

Suggested change
expect(e.cause.message).toEqual("request timed out after 1ms");
expect(e.cause.message).toEqual("Error: Request timed out after 1ms");

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

That's just the message part. Error, when stringified, already prefixes the "Error: ", where "Error" is the property name.

> console.log(new Error("request timed out"))
Error: request timed out
    at REPL1:1:13

If I'd add that into the message it would look like so when logged:

> console.log(new Error("Error: request timed out"))
Error: Error: request timed out
    at REPL2:1:13

Is this what you're referring to?

expect(e.name).toEqual("MeiliSearchRequestError");
}
});

test(`${permission} key: search should be aborted on already abort signal`, async () => {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't understand the name of this test. Can you explain, or rephrase it, please?

@flevi29
Copy link
Collaborator Author

flevi29 commented Jan 10, 2025

Any reason to switch from method<Type>() to method() as Type?
One example is in indexes.ts: await this.httpRequest.get(...) as IndexObject;, but there are other occurrences of this.

The idea was that when we are calling an external web API, the shape of the response cannot be guaranteed, so we're casting to be explicit about this fact. But you are right, it is an overkill, I'm moving the casting part to HttpRequests.

I feel like config / requestConfig are more familiar field names for configuring the underlying HTTP client/request.

I felt like "RequestInit" is more explicit, because that's literally what it's named and what we're using and allowing via types and it is the standard at this point, while config is more implicit and subjective, even if a lot of people might've gotten used to that one. But I can change it if you insist on it.
https://developer.mozilla.org/en-US/docs/Web/API/RequestInit

It is named "extra", because we're applying 3 layers of RequestInits, once from the method body, then from HttpRequests #requestInit, and then from the method's parameter extraRequestInit. My idea is that I want to be a little more clear or explicit about this fact to reduce confusion, but I do think it can still use some improvements. What do you think?

Also there's an open issue about adding this extra config to all of the methods #1476

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-change The related changes are breaking for the users bug Something isn't working maintenance Issue about maintenance (CI, tests, refacto...)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Timeout implementation for requests should be re-thought
2 participants