This is a follow-on post to one that was resolved last week by clashing involving a cache not invalidating on build that’s somewhat similar in nature but apparently outside the scope of env var NO_CHACHE=1 solution clashing provided. I’m a non-coder and had GPT‑5 draft the specifics for the support guidance I’m needing below. I appreciate any suggestions or guidance and apologize for the lengthy read.

Context

Project: DC_n8n CE QMode w/ WH Processor on Railway VPC, service “mcp‑streamable‑test” (Streamable HTTP MCP JSON‑RPC test service).

Source Repo: DC-AAIA/mcp-streamable-test (branch: main).

Region: us‑west2. One replica. Auth via HTTP Bearer.

Relevant docs I’m instructing GPT‑5 to use as its source of truth as part of a dedicated Abacus AI project knowledge collection: DC-AAIA fork of Railway docs: https://github.com/DC-AAIA/railwayapp-docs

Functional goal: Service is supposed to respond to JSON‑RPC calls (initialize, list_tools, call_tool) per czlonkowski/n8n-mcp spec.

Observed behavior

Despite multiple successful redeploys from GitHub commits (with cache clear toggled), the service is not actually executing the updated server.js code.

Example:

• I added a marker log at the top of server.js v0.0.7:

• console.log(" v0.0.7 handler active!");

• This log never appears in Railway deploy logs.

• Instead I only ever see:

• Raw body: { jsonrpc: '2.0', id: 'init-1', method: 'initialize', ... }

• Parsed method: initialize

• The initialize handler block I added is never reached. The request always falls through to the default JSON‑RPC error:

• { "jsonrpc": "2.0", "id": "init-1", "error": { "code": -32601, "message": "Method not found" } }

Repo verification:

• Screenshot attached shows server.js at repo root alongside package.json.

• Git commit clearly contains the marker log and full handler structure.

Build log verification:

• Clean build, no cached layers. Multiple COPY . /app steps show files copied into container.

• Healthcheck passes (/ route responds).

• Container logs never output the startup marker, proving running service is not reflecting latest code.

Questions

1. Why would Railway deploy show a clean build and healthcheck, but still run a previous version of the service code?

2. Is there any known issue with Nixpacks deployments ignoring updates to repository root files (like server.js)?

3. Beyond the UI “Clear cache” option, is there a way to force a guaranteed image rebuild (e.g. CLI flag or project‑level setting) to ensure deployed containers always reflect current repo commits?

4. Are there best practices to confirm deployed container content at runtime (e.g. log echo of build SHA)?

Artifacts

• Curl test result (from Windows PowerShell):

• {

•   "jsonrpc": "2.0",

•   "id": "init-1",

•   "error": { "code": -32601, "message": "Method not found" }

• }

• Deploy logs excerpt (Aug 18, 2025):

• mcp-streamable-test listening on 8080 at /mcp

• Raw body: …

• method: 'initialize',

• Parsed method: initialize

No v0.0.7 marker log present.

• GitHub repo screenshot: shows server.js (v0.0.7) with marker log at project root.

• Build logs: successful rebuild, healthcheck passed, but deployed service did not reflect code changes.

Goal

Understand why Railway is not serving the updated source code for this service even after clean builds and cache clears. Confirm if this is a platform issue or if additional deployment steps are needed on my side.

Ultimately, I need the deployed service to execute the current repo revision of server.js so JSON‑RPC initialize returns correctly and my n8n MCP integration testing can proceed.

Thanks in advance. I’ve had great support from Railway in the past and just want to make sure I’m aligned to recommended practices here - DC