Account: mpluzhnyk-cyber (mpluzhnyk@biodrook.com, GitHub OAuth)

Project: impartial-comfort - 879506d4-b707-4c46-a659-5da4cb9a5a22

Environment: production - 9ed6f57d-40e9-4250-8fea-5f426070debc

Service: impartial-comfort - 11aac1a4-c866-4081-a718-686ab11aabf0

Plan: Hobby (paid, card on file, confirmed charged)

ISSUE 1 - Volume reports READY and mounted, but the mount point doesn't exist in the container

Volume: impartial-comfort-volume - 6a9112a6-314b-4e7b-8cc0-66165a891cbf

Volume instance: b687892a-5127-4177-841f-e4b9a167a186 - state: READY

Mount path: /data, attached to service 11aac1a4-c866-4081-a718-686ab11aabf0 in the production environment

Platform metadata agrees the volume is attached: project.volumes.volumeInstances (GraphQL) reports state: READY for this instance, and deployment metadata for our latest deployment (126655d4-068b-4144-a1fd-4ec42e293b4d) includes "volumeMounts": ["/data"].

But the running container never actually receives the mount, verified two ways:

1. Diagnostic deployment (id: e5f0c3af-91bd-4b42-bee5-d5366591012e) - temporarily replaced our container CMD with ls -la /data; touch /data/test_file; whoami; id; sleep 300. Output: "ls: cannot access '/data': No such file or directory", running as root (not a permissions issue).

2. Live SSH into the container (railway ssh) on our current deployment, a fresh build from a newly-connected GitHub repo (Dockerfile builder, not CLI-deployed) - same result: "ls: cannot access '/data': No such file or directory".

We tried deleting/recreating the volume, detaching/reattaching, and deploying via both railway up (CLI) and GitHub-connected auto-deploy - same result every time. We currently run without DATABASE_URL/UPLOADS_DIR pointed at /data (ephemeral storage), so our SQLite DB and uploads don't survive a redeploy.

ISSUE 2 - Stuck "Applying N changes" state in the dashboard, doesn't clear even via direct API writes

The dashboard (Service -> Settings) persistently shows an "Applying 2 changes" banner referencing a patch that adds a mount /data on a volume named impartial-comfort-volume-zZIT and creates that volume. That volume was never actually created - project.volumes only ever shows our one real volume (6a9112a6... above). impartial-comfort-volume-zZIT was an earlier failed volume-creation attempt from our own troubleshooting.

environmentStagedChanges(environmentId: "9ed6f57d-40e9-4250-8fea-5f426070debc") returns a staged patch id d12f2190-1b14-4178-8bcc-666aa1a55c28 (created 2026-08-12T13:53:19.090Z) referencing volume 4f094e36-c966-4587-a646-0aaa9d32ca70, which is an orphaned volume we deleted ourselves earlier via volumeDelete. So this staged patch points at a resource that no longer exists.

We tried clearing it ourselves:

1. environmentStageChanges(environmentId, input: {}, merge: false) -> succeeded, returned a new patch 95f01c27-1ae9-46b7-896d-c0fc16c28d42 with an empty patch body.
2. environmentPatchCommitStaged(environmentId, skipDeploys: true) -> succeeded, commit reference explicitly pointed at the new empty patch (.../95f01c27-1ae9-46b7-896d-c0fc16c28d42).

Despite both calls succeeding, a subsequent environmentStagedChanges query and the dashboard UI still return the original stuck patch (d12f2190..., same timestamps, unchanged), still referencing the deleted volume. Reproduced across a full logout/login and a brand-new browser session, so not a client cache issue.

WHAT WE'D LIKE

1. Investigation of why the Volume mount metadata says READY/attached but the container never gets /data - this is our actual blocker (need persistent storage for a small production SQLite DB + uploaded files).
2. If possible, a server-side reset of the stuck staged-changes state for environment 9ed6f57d-40e9-4250-8fea-5f426070debc, since our own API-level clear/commit attempts aren't taking effect on the read side.

Happy to provide additional deployment IDs, logs, or a screen-share if useful. Thanks!