🐛 Issue: App Route fails with “No response is returned” only when running inside Docker container

[mr-kelly]

Summary

After introducing an MCP route, Next.js App Routes fail at runtime with “No response is returned” only when the application is running inside a Docker container.
The same code works correctly in a non-Docker (local) environment.

The issue is caused by a newly added dependency that modifies global runtime state during startup.

---

Expected Behavior

• App Routes (e.g. /api/health) should execute normally in all environments.
• Returning a Response object from a route handler should be correctly recognized by Next.js.
• Behavior should be consistent between local execution and Docker container execution.
• Adding an MCP route should not affect unrelated App Routes.

---

Actual Behavior

• In a Docker container, when executing an App Route, Next.js fails its internal instanceof Response check.
• The runtime throws the error: No response is returned
• The same route works correctly outside of Docker (in my localhost).
• The route handler does return a valid Response, but Next.js fails to recognize it.

---

Root Cause (by Coding Agent)

The newly introduced MCP route brings in a dependency that patches global state at startup via undici/polyfill.

Inside the Docker runtime, this global patch causes a mismatch in the Response constructor used by Next.js, leading to a failed instanceof Response check during App Route execution.

This results in Next.js incorrectly reporting that no response was returned.

This is not an issue with the /api/health implementation itself, but an environment-sensitive side effect of global polyfilling.

---

Steps to Reproduce

1. Build and run the application inside a Docker container.
2. Start the Next.js server.
3. Call an App Route such as /api/health.
4. Observe the runtime error: “No response is returned.”
5. Run the same code outside Docker and observe that it works correctly.

[mr-kelly]

I fix this: #141

You can now use your forked version in your Next.js Docker project by updating your package.json:

                                                                                                                                                       
  {                                                                                                                                                    
    "dependencies": {                                                                                                                                  
      "mcp-handler": "github:mr-kelly/mcp-handler"                                                                                                     
    }                                                                                                                                                  
  }                                                                                                                                                    

Or with a specific commit:

  {                                                                                                                                                    
    "dependencies": {                                                                                                                                  
      "mcp-handler": "github:mr-kelly/mcp-handler#b56032b"                                                                                             
    }                                                                                                                                                  
  }  

[zenandrei]

@mr-kelly thanks, I have the same problem, but I'm not using Docker right now, but I have it locally as well. I'm afraid your fix will not work, it will just delay, at least it does not for me. It just delays the issue until the MCP handler is first loaded.

the real issue is caused by hono, and then propagated via MCP SDK:
modelcontextprotocol/typescript-sdk#1376

what worked for me is downgrading to 1.0.4 that depends on mcp sdk 1.24 which does not have hono dependency. waiting on a proper fix now..

[xqe2011]

@mr-kelly thanks, I have the same problem, but I'm not using Docker right now, but I have it locally as well. I'm afraid your fix will not work, it will just delay, at least it does not for me. It just delays the issue until the MCP handler is first loaded.

the real issue is caused by hono, and then propagated via MCP SDK: modelcontextprotocol/typescript-sdk#1376

what worked for me is downgrading to 1.0.4 that depends on mcp sdk 1.24 which does not have hono dependency. waiting on a proper fix now..

I have a simple solution.

{
  "dependencies": {
    "mcp-handler": "^1.0.7"
  },
  "overrides": {
    "@modelcontextprotocol/sdk": "1.25.3"
  }
}

Since @modelcontextprotocol/sdk:1.25.3, they are using a new version of hono, which doesn't modify Response class globally, so this issue will not happen.