Summary: The ECONNRESET error at ~30 seconds is caused by the Databricks Apps managed ingress request router, which strictly terminates long-running synchronous HTTP requests to protect platform stability. Local framework configurations (like Next.js maxDuration or FastAPI timeouts) apply only to the container and cannot override these platform-level gateway limits. To fix this, Databricks best practices dictate implementing an asynchronous "status pull" (polling) pattern.

Why Your App is Disconnecting Databricks Apps operate within a managed Serverless Compute Plane and sit behind a Databricks-controlled Request Router. This routing layer actively monitors connection health and enforces strict timeouts on synchronous requests (often dropping them if no data is passed within ~30-120 seconds). When your Next.js frontend waits synchronously for FastAPI (which is in turn waiting ~60 seconds for the AgentBricks endpoint), the Databricks ingress proxy assumes the connection has hung and forces a disconnect (ECONNRESET). Because the timeout happens upstream at the proxy layer, your FastAPI process remains unaware and finishes the task normally in the background.

The Recommended Solution: "Status Pull" Pattern To accommodate workloads like long-running AI agents that exceed gateway timeout thresholds, you must re-architect the interaction between Next.js and FastAPI to use an asynchronous polling model:

1. Trigger and Return: Update your initial FastAPI endpoint (/api/demo/alerts) so that it kicks off the AgentBricks call as a background task. It should immediately respond to Next.js with an HTTP 202 (Accepted) status and a unique task_id.
2. Implement a Status Endpoint: Create a secondary FastAPI endpoint (e.g., /api/demo/alerts/status/{task_id}) that checks the state of the background task (e.g., pending, processing, or complete).
3. Poll from Next.js: Configure your Next.js frontend to periodically ping the status endpoint (for example, every 3–5 seconds) until the Agent finishes processing and the final response payload is ready to be fetched and displayed.

This pattern circumvents the platform's ingress timeout limits, frees up UI threads, and is the standard runtime performance recommendation for heavy or long-running tasks on Databricks Apps.