We checked that patch against your production environment and it contains zero effective staged changes. The record exists (every environment holds one) but its contents are empty, so there is nothing to apply, nothing to discard, and no risk to your running configuration. The dashboard is correct in not showing a staged-changes banner, since the banner is driven by the change count, not by the record's existence. Your production services are running normally with their last successful deployments intact.

Thank you. I would like to clarify one discrepancy before considering this resolved.

Railway's MCP get-staged-changes previously reported 22 effective changes for this exact same staged patch ID, including removal of existing production environment variables.

At the same time, you have now checked the patch against production and report zero effective staged changes.

Could you please confirm why get-staged-changes reported those 22 changes, and confirm that committing/deploying this existing staged patch would currently result in ZERO configuration changes?

I will not commit or deploy anything; I only want to understand the discrepancy and confirm that the production environment is safe.

Thank you.

Staged patch records persist even after their contents are cleared: a discard operation rewrites the contents to empty but leaves the record in place with the same ID. The authoritative signal is the change count inside the patch, not the record's existence or its status fields. Our check of your production environment shows zero effective staged changes in that patch right now, so the dashboard is correct in not rendering a staged-changes banner. A deploy in that environment would apply zero configuration changes to your running services.

The issue is NOT resolved after a fresh read-only verification.

I have now re-checked the production environment without making any mutations.

For the exact same staged patch:

2ac3feeb-8152-4b8f-8535-c67d8c7e1a3f

Railway's read-only MCP get-staged-changes still reports:

changeCount: 22

Those effective changes include:

• removal of all 6 existing environment variables from sybyrshy-2
• removal of all 12 PostgreSQL variables from Postgres-GyN7
• removal of the Postgres Stacker Assignment
• 3 volume alert additions

In addition, both production services currently report:

state: "live-with-staged-changes"

The live services themselves are still healthy and their current variables remain intact, because the patch has not been applied.

The Dashboard still does not show a staged-changes banner.

So there is now a direct contradiction:

1. Railway's automated support response says the patch has zero effective changes.
2. Railway's own read-only MCP reports 22 effective changes that accept-deploy would commit.
3. The service configuration state reports live-with-staged-changes.

Please escalate this to a Railway engineer / human support reviewer.

I need confirmation based on the actual backend state of this patch, not an automated interpretation.

Please DO NOT commit, deploy, or mutate the production environment.

If possible, please either:

• safely clear this staged patch server-side, or
• explain why get-staged-changes is returning these 22 destructive changes and why both services report live-with-staged-changes.

Until this discrepancy is resolved I will not deploy or modify this production environment.

Thank you.

We re-checked the production environment just now and verified both services independently via their committed configuration: all 12 Postgres variables and all 6 application-service variables are present and intact, and both services are running on successful deployments, so your production environment is safe as it stands. Our staged-changes check returns a zero change count for this environment, which is why the dashboard renders no staged-changes banner. The 22-change reading your MCP connector is returning is a discrepancy we cannot account for from our side, and we understand your caution in not deploying until it is explained.

Corroborating report — same discrepancy, different project shape.

Project: courteous-liberation / 418c535d-1e1f-410a-a16e-1fb28437be1c

Environment: production / 2358dd33-e8d5-4b23-8d53-9d5c7a771da8

Patch ID: 12e431ce-525d-4cb0-b0e8-77d3c31ea93a, status STAGED, changeCount 25

get-staged-changes reports 25 removals: all 24 service variables, plus networking.customDomains.[my-domain].port. It flags the patch destructive: false. describe-environment reports the service as live-with-staged-changes with stagedChangeCount: 25.

The dashboard disagrees, exactly as described above. No staged-changes banner on the canvas, none on the service's Deployments tab, no entry in the environment dropdown or project settings, and the Variables tab lists all 24 variables present and intact. The service is healthy on its most recent deploy and a scheduled job ran normally this morning using those variables.

Three details that may help isolate it:

1. This environment has one Node.js service — no Postgres, no volumes, no buckets. The other reports involve Postgres and volume changes, so the common factor is not resource type.
2. createdAt and updatedAt on the patch are identical to the millisecond, so nothing accumulated into it incrementally.
3. The patch timestamp is 4.5 hours after the last real deployment, and I cannot account for any config change in that window.

That pattern looks like the connector diffing live config against an empty patch record and rendering the entire config as removals.

Not deploying. Happy to run any read-only call against this environment if it helps narrow it.

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