We checked the production environment on your AiD Me project and it holds zero effective staged changes right now, which matches the Railway Agent's "remaining staged changes: 0" result. There is nothing pending that would be deployed, and your running deployments and committed configuration are unaffected. The status: STAGED and changeCount: 56 you are seeing from the API reflect the old patch record that the discard emptied but did not remove; the actual change inventory inside that record is empty.

Thanks. Can you please confirm whether the staged section still returned by the service configuration API is also just stale metadata?

For aidme-backend, the API still reports the same patch ID with changeCount: 20, including staged variable names and a networking change.

If these are definitely non-effective/stale records and cannot be deployed, please confirm that it is safe for me to make new configuration changes and deploy normally without those old 56 items being included.

We re-checked your production environment just now and the patch contents are empty (zero changes), including for aidme-backend. The changeCount and variable/networking entries the service configuration API still reports come from the patch record that the discard emptied but did not delete. The authoritative signal is the change inventory inside the patch contents, not the record's status field or its reported count. It is safe to make new configuration changes and deploy normally: nothing from the old 56-item patch will be included.

Update — I’ve now ruled out the source chunk size as the cause.

I rebuilt the exact same backend source from 4 chunks (~3.2 KB each) into 8 smaller chunks (~1.6 KB each).

The 8 chunks:

• reconstruct byte-for-byte correctly locally
• pass syntax checks
• are well below Railway’s documented 96 KB Function source limit

Fresh backend deployments still fail during startup with:

base64: invalid input

during:

Analyzing index.tsx

Example failed deployment:

d07d56d2-6bab-4803-b63f-57bb8ecf6897

I then tested this independently by creating an isolated plain Node 22 Alpine service, containing only a tiny HTTP /health server — no Function source encoding and no TTS/OpenAI logic.

That deployment is now stuck indefinitely at:

CREATE_CONTAINER — pending

with:

• 0 running replicas
• no runtime logs
• Node process never starts
• healthcheck never begins

Node test deployment:

43111fdf-3069-466a-bb19-58eea4625864

Service: aidme-voice-v3

Meanwhile my existing production backend deployment:

b0c5975a-3bef-4906-a48b-dee19f670a92

remains healthy with 1 running replica and continues serving production traffic normally.

This now appears to affect fresh container/deployment creation, rather than just my application source.

Could someone from Railway please inspect these two deployment IDs at the platform/control-plane level, particularly why fresh Function containers report base64: invalid input and why the plain Node deployment never progresses beyond CREATE_CONTAINER?

Please do not modify or replace the currently running production deployment b0c5975a-3bef-4906-a48b-dee19f670a92.

This was a bug in how our API and MCP tools counted staged changes, and it is now fixed.