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

After SOFA v0.12.0 upgrade, "Variable X of required type String! not provided" errors for multiple mutations #1174

Open
kleydon opened this issue Sep 24, 2022 · 6 comments

Comments

@kleydon
Copy link

kleydon commented Sep 24, 2022

After upgrading from Sofa v0.11.2 to v0.12.0, parameters provided in the body of my REST requests are no longer found/recognized by SOFA's auto-generated REST API. If I switch back to SOFA v0.11.2, my requests work again.

For example, my login request http://localhost:2020/auto-rest/auth-login-by-phone, made with the body: { "phone": "+12676146833" } yields the error:

Variable "$phone" of required type "String!" was not provided.

It doesn't matter whether I'm running on localhost on a MacBook (http) or on gcloud run (https); it doesn't matter whether I make the request via Postman or via a Swagger REST UI - the error is consistently the same. The error occurs in response to multiple requests with body parameters (that correspond to mutations).

When I examine the request (above), as received by the context function provided to my useSofa() function (below), the request DOES (at this point) contain the expected string value for phone; { "phone": "+12676146833" }

  const openApi = OpenAPI({ schema })
  app.use(
    autoRestApiBaseRoute,
    useSofa({
      schema,
      basePath: autoRestApiBaseRoute,
      context: (request: any) => {
        return {
          ...request,
          prisma,
        }
      },
      depthLimit: 2,
      onRoute(info:any) {
        openApi.addRoute(info, {
          basePath: autoRestApiBaseRoute
        })
      }
    })
  )
  app.use(autoRestApiDocsRoute, swaggerUi.serve, swaggerUi.setup(openApi.get()))
}

Some additional context:

The relevant portion of my GraphQL Schema:

...
type Mutation {
  ...
  authLoginByPhone(phone: String!): StringPayload!
  ...
}  
...

My authLoginByEmail() resolver, created using type-graphql:

  @Mutation(returns => StringPayload)
  async authLoginByEmail(
    @Ctx() ctx: Context,
    @Info() info: GraphQLResolveInfo,
    @Arg('email') email: string,  //email address
  ): Promise<StringPayload> {
    ilog('authLoginByEmail():')
    const session = ctx.request.session
    const result = await logInByEmail({ email, session })
    return result
  } 

I've looked through the release notes for v0.12.0, and don't yet see anything that would need to change in my code, between v0.11.2 and v.0.12.0 - but perhaps I'm wrong? If you have any recommendations - or know how I could debug further "downstream" than the body of the context function, (mentioned above) - I'd love to know about it. It does seem like this is a bug though, from what I can see so far.

@ardatan
Copy link
Collaborator

ardatan commented Sep 24, 2022

Please share a minimal and clear reproduction on CodeSandbox or StackBlitz

@kleydon
Copy link
Author

kleydon commented Sep 24, 2022

Hi @ardatan,

I've just posted a minimal and clear reproduction on GitHub here, and a slightly modified version on CodeSandbox here. The README describes how to reproduce the issue.

If any additional info would be useful, please let me know.

@MejanH
Copy link

MejanH commented Nov 6, 2022

Yes, I am also facing this issue. made sure the body-parser is working. but still the same issue. it's working with only url params. for me, I was using v0.15.0.

@DanielHefti
Copy link

I'm facing the same issue, too. I have tried it with version 0.15.1.

@mhaagens
Copy link

mhaagens commented Feb 16, 2023

Same issue here.
Seems like POST routes doesn't accept Content-Type: application/json as a header, only Content-Type: text/plain

@oleg-prikhodko
Copy link

I've run into this issue while integrating SOFA with Nest. Disabling bodyParser on app instance actually solved the problem.

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

6 participants