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

"API resolved without sending a response" appearing on every route despite the API routes working fine. #30

Closed
drkgrntt opened this issue Feb 8, 2020 · 8 comments · Fixed by #38

Comments

@drkgrntt
Copy link

drkgrntt commented Feb 8, 2020

I recently switched from an Express server to NextJS's API pages, and I love the way this repo helps with that, so thank you!

That said, all of my API routes are logging "API resolved without sending a response". This issue was posted 3 days ago in nextjs's issues and was closed the next day with this comment being the solution to it. I was wondering if the solution could be implemented into this repo. It looks like the OP was using async/await and the comment that solved the problem recommended returning a Promise instead. In my particular case, all my my routes are printing the message, regardless of if they are asynchronous or not. One example is the following:

import connect from "next-connect"
import common from "../../../middleware/common/"
import keys from "../../../config/keys"

const handler = connect()
handler.use(common)

handler.post((req, res) => {
  return res.status(200).send(keys.googleMapsKey)
})

export default handler

It's possible my problem lies elsewhere, but since all of my routes are going through next-connect, I figured this might be something to be looked at within the repo.

@hoangvvo
Copy link
Owner

hoangvvo commented Feb 9, 2020

import connect from "next-connect"
import common from "../../../middleware/common/"
import keys from "../../../config/keys"

const handler = connect()
handler.use(common)

handler.post((req, res) => {
  return res.status(200).send(keys.googleMapsKey)
})

export default (req, res) => handler.apply(req, res) 

Hi @drkgrntt, can you try doing this instead?

@franklinjavier
Copy link

It worked with handler.apply

@drkgrntt
Copy link
Author

This seems to work! In the readme, .apply(req, res) is only mentioned at the very end for middleware and getInitialProps. Is there something I missed that would indicate that I need to do that in all of my API endpoints?

@hoangvvo
Copy link
Owner

hoangvvo commented Feb 11, 2020

@drkgrntt I did not include this because it was not the case until #9999. See this comment

handler does not resolve into a promise, but acts more like a callback thing, so Next.js throws that warning.

Howevere, it is just a harmless warning and should not cause any actual error in production as long as we handle every thing right in creating the middleware

@drkgrntt
Copy link
Author

Great! Thank you for the quick responses.

Janaka-Steph pushed a commit to Janaka-Steph/binance-blog that referenced this issue Feb 19, 2020
@throwarray
Copy link

The .apply fix mentioned doesn't handle errors and leads to requests hanging.
The intention here would be to have 'not found' returned since there's no GET handler

const router = nextConnect()

router.post(function (req, res) { res.end('ok') })

export default function (req, res) { return router.apply(req, res) }

Maybe a method could be added that basically does this

connect.apply = function apply(req, res) {
  return new Promise((resolve) => this.handle(req, res, function (err) {
      if (err) onError(err, req, res)
      
      else onNoMatch(req, res)

      resolve()
  }))
}

@hoangvvo
Copy link
Owner

@throwarray Thanks, will be handled in #38.
.apply is not always use as a route handler so I would not call .onError. However, it should reject the promise.

@hoangvvo
Copy link
Owner

The next version will always return a promise so we do not need to use .apply to avoid that error anymore

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

Successfully merging a pull request may close this issue.

4 participants