[BUG] MCP data-query backend ignores configured engine URL in container deployments #387

Summary

The server-side MCP data-query backend ignores NEXT_PUBLIC_WWV_PLUGIN_DATA_ENGINE_URL and always constructs the data-engine URL as http://localhost:${NEXT_PUBLIC_WWV_LOCAL_ENGINE_PORT || 5001}.

This breaks containerized/self-hosted deployments where WorldWideView and wwv-data-engine run as separate services. Inside the WWV container, localhost refers to WWV itself, not the engine container. As a result, /api/health reports engine: false and MCP data tools return plugin_not_streaming, even though the engine is healthy and reachable over the Compose network.

This appears related to, but is not covered by, #182: the currently affected file is src/lib/data-query/service.ts, which was not listed there, and the hardcoded URL remains on the current default branch.

Current code

export function getEngineUrl(): string {
    const port = process.env.NEXT_PUBLIC_WWV_LOCAL_ENGINE_PORT || '5001';
    return `http://localhost:${port}`;
}

fetchEngineSnapshot() and getAllPluginSnapshots() both call this function, so all MCP/server-side engine queries are affected.

Reproduction

1. Run WWV and the data engine as separate Docker Compose services.

2. Configure WWV with:

   environment:
     NEXT_PUBLIC_WWV_PLUGIN_DATA_ENGINE_URL: http://wwv-data-engine:5000

3. Confirm from the WWV container that http://wwv-data-engine:5000/health succeeds.

4. Call WWV /api/health or an MCP data tool such as list_available_plugins.

Actual result

WWV attempts to connect to http://localhost:5001; health reports the engine unavailable and MCP queries cannot see streaming plugins.

Expected result

Server-side data queries should honor an explicitly configured engine base URL. A private server-only variable is preferable for Compose/internal DNS, while retaining the existing public variable as a compatibility fallback.

Proposed patch (tested)

The following patch is running successfully in an ARM64 self-hosted deployment with WWV and the engine in separate containers:

diff --git a/src/lib/data-query/service.ts b/src/lib/data-query/service.ts
--- a/src/lib/data-query/service.ts
+++ b/src/lib/data-query/service.ts
@@
 export function getEngineUrl(): string {
+    const configuredUrl = process.env.WWV_PLUGIN_DATA_ENGINE_URL
+        || process.env.NEXT_PUBLIC_WWV_PLUGIN_DATA_ENGINE_URL;
+    if (configuredUrl) return configuredUrl.replace(/\/+$/, "");
     const port = process.env.NEXT_PUBLIC_WWV_LOCAL_ENGINE_PORT || '5001';
     return `http://localhost:${port}`;
 }

Example Compose configuration:

services:
  wwv:
    environment:
      WWV_PLUGIN_DATA_ENGINE_URL: http://wwv-data-engine:5000

The trailing-slash normalization prevents URLs such as http://engine:5000//manifest. The old localhost/port behavior remains the fallback, so local development remains backward-compatible.

Validation

After applying the patch in the described deployment:

{"status":"healthy","checks":{"redis":true,"db":true,"engine":true,"config":true},"edition":"local"}

MCP list_available_plugins also began returning the engine-backed feeds instead of reporting them as plugin_not_streaming.