4 days ago
Please investigate and reconcile Railway's GitHub deployment status publication. A successful serving deployment is still reported as failure by railway-app[bot], blocking our protected release workflow.
Repository: peterheijen2026-glitch/pet-delivery-control-plane
Commit: 6509b5b7ec8085ea7afdf553955eb21396983b73
Project: f3a29e22-77c6-4f3e-a958-a515f1e97915
Environment: shadow / 418f39d1-b4e6-4246-bfee-4e07e9ee4c90
Service: pet-dcp-shadow / 3f415c5e-9887-4f4a-b4bd-3c6182bba91f
Successful Railway deployment: 8f8ca7f8-5f61-4dd6-800d-788bf534ac20
GitHub deployment: 6679239216
On 2026-09-26 a volume-mount permission problem caused deployment 4e073142-dd1a-4c2a-85fc-a413053f28f4 to fail. After detaching the volume, deployment 25204988-2ece-4da0-ab59-9a79a6e681c7 recovered successfully. A native redeploy (8515826c-855c-4345-85e5-2a46b160889d) and then Deploy Latest Commit (8f8ca7f8-5f61-4dd6-800d-788bf534ac20) both succeeded on the same main SHA. The latter succeeded at 14:58:34 UTC.
However, Railway published GitHub failure statuses at 14:58:37 and 14:59:26 UTC, with empty descriptions and project-level log URLs. Our investigation found Railway still reporting SUCCESS and /ready returning {ready:true} at https://pet-dcp-shadow-shadow.up.railway.app/ready.
Example blocked protected release: https://github.com/peterheijen2026-glitch/pet-delivery-control-plane/actions/runs/36256300135 — pending_live / provider_deployment_not_successful at 16:40:48 UTC.
Could an older failed/removed deployment of the same SHA be affecting the aggregate status? This is a hypothesis, not an established cause. Please investigate, reconcile the authentic provider status and advise how to prevent recurrence. We have not fabricated a GitHub success or bypassed the release check.
A separate dcp-kernel-232-shadow service created later on a different branch/SHA is not the target of this request. No credentials or customer data are included.
3 Replies
Status changed to Awaiting Railway Response Railway • 4 days ago
4 days ago
Material update/correction after a fresh read of both Railway and GitHub:
The original service pet-dcp-shadow (3f415c5e-9887-4f4a-b4bd-3c6182bba91f) is now offline. Its latest Railway deployment 498625cc-19c9-42ef-9371-20fe998c8164, started 2026-09-26 22:04 UTC, failed the /ready healthcheck. Deploy logs show sqlite3.OperationalError: unable to open database file, followed by pet_dcp.domain.ContractViolation: could not open or validate inbox/outbox database, while volume vol_4omv71q7lyy9n1fj is mounted. The public /ready URL now returns Railway 404 Application not found with x-railway-fallback:true.
GitHub deployment 6679239216 therefore correctly has a latest failure status at 22:05:33 UTC for the current state. The earlier Railway deployment 8f8ca7f8-5f61-4dd6-800d-788bf534ac20 is shown as REMOVED. Our earlier report that the serving deployment was still healthy is no longer current.
The earlier question remains relevant for the 14:58 UTC discrepancy, but the immediate blocker is now the mounted-volume/database permission startup failure. Please advise the supported way to initialize ownership/permissions for a volume used by a container that drops privileges, and whether removed successful redeployments are expected to update the same GitHub deployment object with later failure states. No status was fabricated and no release gate was bypassed.
4 days ago
Fresh reproduction at 2026-09-27 07:21 UTC:
Railway deployment 65eeb945-f64e-4429-afdf-3b399a672272 is now internally SUCCESS on the original service 3f415c5e-9887-4f4a-b4bd-3c6182bba91f, with commitHash exactly 6509b5b7ec8085ea7afdf553955eb21396983b73. The public https://pet-dcp-shadow-shadow.up.railway.app/ready now returns HTTP 200 and {"ready":true}.
F
However, railway-app[bot] published failure twice to GitHub deployment 6679239216 at 07:21:26Z and 07:21:28Z, immediately after the in_progress status at 07:21:04Z. Descriptions are empty. There is no later GitHub success at this time.
This reproduces the original mismatch on a currently healthy, exact-main deployment. Please reconcile the GitHub deployment status and investigate why an internal SUCCESS results in two GitHub failure statuses.resh reproduction at 2026-09-27 07:21 UTC:
Railway deployment 65eeb945-f64e-4429-afdf-3b399a672272 is now internally SUCCESS on the original service 3f415c5e-9887-4f4a-b4bd-3c6182bba91f, with commitHash exactly 6509b5b7ec8085ea7afdf553955eb21396983b73. The public https://pet-dcp-shadow-shadow.up.railway.app/ready now returns HTTP 200 and {"ready":true}.
However, railway-app[bot] published failure twice to GitHub deployment 6679239216 at 07:21:26Z and 07:21:28Z, immediately after the in_progress status at 07:21:04Z. Descriptions are empty. There is no later GitHub success at this time.
This reproduces the original mismatch on a currently healthy, exact-main deployment. Please reconcile the GitHub deployment status and investigate why an internal SUCCESS results in two GitHub failure statuses.
3 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 3 days ago
peterheijen2026-glitch
Fresh reproduction at 2026-09-27 07:21 UTC: Railway deployment 65eeb945-f64e-4429-afdf-3b399a672272 is now internally SUCCESS on the original service 3f415c5e-9887-4f4a-b4bd-3c6182bba91f, with commitHash exactly 6509b5b7ec8085ea7afdf553955eb21396983b73. The public https://pet-dcp-shadow-shadow.up.railway.app/ready now returns HTTP 200 and {"ready":true}. F However, railway-app[bot] published failure twice to GitHub deployment 6679239216 at 07:21:26Z and 07:21:28Z, immediately after the in_progress status at 07:21:04Z. Descriptions are empty. There is no later GitHub success at this time. This reproduces the original mismatch on a currently healthy, exact-main deployment. Please reconcile the GitHub deployment status and investigate why an internal SUCCESS results in two GitHub failure statuses.resh reproduction at 2026-09-27 07:21 UTC: Railway deployment 65eeb945-f64e-4429-afdf-3b399a672272 is now internally SUCCESS on the original service 3f415c5e-9887-4f4a-b4bd-3c6182bba91f, with commitHash exactly 6509b5b7ec8085ea7afdf553955eb21396983b73. The public https://pet-dcp-shadow-shadow.up.railway.app/ready now returns HTTP 200 and {"ready":true}. However, railway-app[bot] published failure twice to GitHub deployment 6679239216 at 07:21:26Z and 07:21:28Z, immediately after the in_progress status at 07:21:04Z. Descriptions are empty. There is no later GitHub success at this time. This reproduces the original mismatch on a currently healthy, exact-main deployment. Please reconcile the GitHub deployment status and investigate why an internal SUCCESS results in two GitHub failure statuses.
an hour ago
Su
re we will considering that thanks