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

Help catch non declared query or path parameters #1000

Open
mikavilpas opened this issue Sep 3, 2024 · 11 comments
Open

Help catch non declared query or path parameters #1000

mikavilpas opened this issue Sep 3, 2024 · 11 comments
Labels
feature 🚀 New feature or request prioritized 🚚 This issue has been prioritized and will be worked on soon
Milestone

Comments

@mikavilpas
Copy link
Contributor

Description

Hi, and thanks for this wonderful project!

At work, my team ran into an issue where we were accidentally passing in path parameters instead of query parameters, causing a profile search api to return a much larger dataset than what we expected 🙂

diff --git a/packages/server/src/services/employments/temporaryEmployments.ts b/packages/server/src/services/employments/temporaryEmployments.ts
index f69e2a0..a2cf2aa 100644
--- a/packages/server/src/services/employments/temporaryEmployments.ts
+++ b/packages/server/src/services/employments/temporaryEmployments.ts
@@ -9,7 +9,7 @@ export const getTemporaryEmployments = async (profileId: string): Promise<V1Temp
   try {
     const response = await EmploymentService.searchTemporaryEmployments({
       client,
-      path: { profileId },
+      query: { profileId },
     })
     return response.data
   } catch (error) {

The generated data type for this api does not declare path options in the openapi specification. It's defined as /v0/temporaryEmployment/search:.

It looks like the defaults come from

interface RequestOptionsBase<ThrowOnError extends boolean> extends Config<ThrowOnError> {
    path?: Record<string, unknown>;
    query?: Record<string, unknown>;
    url: string;
}

Is there a way to disallow specifying parameters that are not defined by the API specification?

@mikavilpas mikavilpas added the feature 🚀 New feature or request label Sep 3, 2024
@mrlubos
Copy link
Member

mrlubos commented Sep 3, 2024

@mikavilpas Can you share your OpenAPI spec?

@mikavilpas
Copy link
Contributor Author

I can't share the full spec, but I created a reproduction setup here https://github.com/mikavilpas/hey-api-reproduction-1000

Let me know if this helps.

@mrlubos
Copy link
Member

mrlubos commented Sep 4, 2024

@mikavilpas Oh so you're asking for strict types? That is, unless something is explicitly defined as a possible value by the spec, don't allow it to be passed?

@mikavilpas
Copy link
Contributor Author

Yes, that's it! If there's any way to opt into this kind of behaviour, it would be perfect.

I'm building a new openapi client for our company's internal api with my team, and it would be great to enforce strict adherence to the spec like this.

@mrlubos
Copy link
Member

mrlubos commented Sep 4, 2024

I'd need to think about it, this would have to be done on the (fetch/axios) client level. If you can think of anything feel free to open a pull request! We'd need to modify the types to either be more strict or loose as they're now depending on some generic variable

@mikavilpas
Copy link
Contributor Author

I have an idea. It seems like it might be enough to add a missing path or query parameter into the generated types as an explicitly disallowed parameter:

diff --git a/examples/openapi-ts-fetch/src/client/types.gen.ts b/examples/openapi-ts-fetch/src/client/types.gen.ts
index 9dbad3c8..3d90d297 100644
--- a/examples/openapi-ts-fetch/src/client/types.gen.ts
+++ b/examples/openapi-ts-fetch/src/client/types.gen.ts
@@ -118,6 +118,7 @@ export type UpdatePetResponse = Pet;
 export type UpdatePetError = unknown;
 
 export type FindPetsByStatusData = {
+  path?: undefined;
   query?: {
     /**
      * Status values that need to be considered for filter
hey-api.mov

@mrlubos
Copy link
Member

mrlubos commented Sep 5, 2024

This would then shift the ownership over strictness to the generator instead of the client, correct? I could get behind that. My immediate reaction is we'd want a types.strict optional boolean flag. Did you have a different idea?

@mikavilpas
Copy link
Contributor Author

Yeah I think it would have to be done in each client with this solution 🤔

@mikavilpas
Copy link
Contributor Author

Oh wait, did I get it backwards?

@mrlubos
Copy link
Member

mrlubos commented Sep 5, 2024

As long as the client understands path?: undefined (or even never) and resolves it to disallow arbitrary values, that would accomplish what we need here. I like this idea!

@mrlubos mrlubos added the prioritized 🚚 This issue has been prioritized and will be worked on soon label Sep 30, 2024
@mrlubos mrlubos added this to the Parser milestone Oct 20, 2024
@mrlubos
Copy link
Member

mrlubos commented Oct 20, 2024

Added this to the Parser release. Thanks for your patience!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature 🚀 New feature or request prioritized 🚚 This issue has been prioritized and will be worked on soon
Projects
None yet
Development

No branches or pull requests

2 participants