Skip to content

If I don't specify default response, I get a TS error on endpoint request #16

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

Closed
hukus opened this issue Jan 25, 2022 · 3 comments
Closed

Comments

@hukus
Copy link

hukus commented Jan 25, 2022

If I don't specify default response, I get a TS error on endpoint request. The error says following:

TypeError: Cannot destructure property 'responseParameters' of 'chosenResponse' as it is undefined.

If I add default response, it works.
This is probably not desired, as 200 should be automatically the default response.
I traced the problem to serverless-offline package, specifically to HttpServer.js file where the responses are parsed.

EXAMPLES
Settings that are cause error:

    events:
      - http:
          method: get
          path: /transports
          cors:
            origin: '*'
            headers: '*'
          responses: 
            200:
              description: 'List of possible transport options'
              bodyType: 'TransportsResponseType'
            400:
              bodyType: 'GeneralErrorType'

Settings that work OK:

    events:
      - http:
          method: get
          path: /transports
          cors:
            origin: '*'
            headers: '*'
          responses: 
            default: 
              description: 'Use this endpoint to list possible options for transport of material and parts'
            200:
              description: 'List of possible transport options'
              bodyType: 'TransportsResponseType'
            400:
              bodyType: 'GeneralErrorType'
@desaintvincent
Copy link
Contributor

I had the same issue, traced, conclude and fixed it the same way. Maybe this serverless-auto-swagger can add default to the first response (would be 200 in your case) if there is not already one?

This solution feels like a dirty piece of tape.

On the other hand, is it serverless-auto-swagger's responsability to do that?

An other solution could be to use something like swaggerResponse instead of response, but that would cause breaking change...

I can do the PR if you want, but we should find a smart solution that @SamWSoftware agrees with

@bfaulk96
Copy link
Collaborator

bfaulk96 commented Feb 8, 2022

Instead of using responses, use responseData.
We should probably remove support for using the existing responses object since it seems to cause problems (I also ran into issues when using serverless 3.0 and trying to use responses instead of responseData

@desaintvincent
Copy link
Contributor

thanks @bfaulk96 ! I think we can now close this issue

@hukus hukus closed this as completed Feb 10, 2022
dustinsgoodman added a commit to thisdot/starter.dev that referenced this issue Jan 1, 2023
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

3 participants