From b5cf0205db2b6e8c4b696d936661ab0fcfecb559 Mon Sep 17 00:00:00 2001 From: AJ Date: Thu, 10 Sep 2026 19:03:57 +0800 Subject: [PATCH] fix: remove root Dockerfile -- restore Railway to Nixpacks (production outage) URGENT: api.xfinlab.com has been returning 502 on every request (real user traffic and the MCP endpoint alike) since PR #51 added a root Dockerfile for Glama.ai's MCP listing verification. PR #52 fixed the missing-litestream build failure, but the deploy still never actually serves traffic afterward: "Completed" status, but 0% CPU/memory for a sustained window, deploy logs go silent right after litestream restore finishes its last WAL entry, and every live request times out at Railway's 15s gateway limit with a 502. railway.json explicitly pins "builder": "NIXPACKS", but the mere presence of a root Dockerfile appears to make Railway build with it instead -- the same behavior that caused PR #51's original failure. Whatever additional difference exists between the Docker-built image and the previously-working Nixpacks-built image (permissions, base image, etc.) leaves the app unable to ever start serving, with no error logged. Removing the Dockerfile is safe: Glama's own "Server" build flow never actually reads this file (it clones the repo and generates its own Dockerfile from a template internally, confirmed by inspection). The XFINLAB MCP listing on Glama was instead submitted via their "Connector" flow (a plain HTTPS URL, glama.ai/mcp/servers -- Connectors -- XFINLAB Intelligence), which needs no Dockerfile at all. The originating requirement (punkpeye/awesome-mcp-servers PR #13369) is also now closed. This restores the exact build path (nixpacks.toml) that was working correctly before 2026-09-09. --- Dockerfile | 58 ------------------------------------------------------ 1 file changed, 58 deletions(-) delete mode 100644 Dockerfile diff --git a/Dockerfile b/Dockerfile deleted file mode 100644 index cf522df..0000000 --- a/Dockerfile +++ /dev/null @@ -1,58 +0,0 @@ -FROM python:3.10-slim - -WORKDIR /app - -# 2026-09-09 (Glama.ai MCP server listing requirement, per the -# awesome-mcp-servers PR feedback): Glama builds and runs this Dockerfile -# directly to verify the MCP server actually starts and responds to -# introspection requests, rather than only checking the live production -# URL. Kept intentionally minimal/production-only -- no ffmpeg/fonts (the -# Video Engine's own is_available() check already degrades gracefully -# without them, same as on Railway if that apt layer were ever missing) -# and no requirements-dev.txt (test-only deps, irrelevant to booting the -# app). -# -# build-essential is included defensively in case QuantLib (a compiled -# C++ library with Python bindings) doesn't ship a prebuilt wheel for -# whatever platform Glama builds on -- without it, that one line in -# requirements.txt could fail to install and take the whole build down. -# -# curl is needed for the litestream install step below. -RUN apt-get update && apt-get install -y --no-install-recommends \ - build-essential \ - curl \ - && rm -rf /var/lib/apt/lists/* - -COPY requirements.txt . -RUN pip install --no-cache-dir -r requirements.txt - -COPY . . - -# 2026-09-09 fix (real Railway outage): railway.json's own "deploy.startCommand" -# always runs `/app/bin/litestream ...` to wrap uvicorn (continuous SQLite -# replication), regardless of which builder actually produced the image. -# Adding this Dockerfile in PR #51 caused a real production deploy failure -- -# "The executable /app/bin/litestream could not be found" -- because Railway -# built from THIS file instead of nixpacks.toml (which is where litestream -# was previously installed, in its own [phases.litestream] block) even -# though railway.json pins "builder": "NIXPACKS". Installing the identical -# binary here (same version/URL as nixpacks.toml) makes this Dockerfile -# correct no matter which builder Railway or any other platform picks. -RUN mkdir -p /app/bin \ - && curl -L https://github.com/benbjohnson/litestream/releases/download/v0.3.13/litestream-v0.3.13-linux-amd64.tar.gz -o /tmp/litestream.tar.gz \ - && tar -xzf /tmp/litestream.tar.gz -C /app/bin \ - && chmod +x /app/bin/litestream \ - && rm -f /tmp/litestream.tar.gz - -# Same placeholder pattern already proven in .github/workflows/ci.yml: -# services/news_service.py's NewsService.__init__ only checks that -# NEWS_API_KEY is *present* at import time -- it never calls the real -# NewsAPI just to let backend.main import successfully. Real deployments -# (Railway) set a genuine key via their own env vars; this container only -# needs to boot and answer MCP introspection, not serve real news data. -ENV NEWS_API_KEY=docker-build-placeholder-not-a-real-key -ENV PORT=8000 - -EXPOSE 8000 - -CMD ["sh", "-c", "PYTHONPATH=/app uvicorn backend.main:app --host 0.0.0.0 --port ${PORT}"]