8 hours ago
Hello Railway team/community,
I need clarification of the public API contract for verifying permanent deletion of disposable resources, not help debugging application code.
The schema exposes serviceInstance: ServiceInstance! and volumeInstance: VolumeInstance!. After soft deletion, resource lookups may still return service metadata or a volume instance with state DELETED.
- What exact supported API response proves permanent absence, distinct from authentication, authorization or transient errors? Is there a documented structured not-found error/code for these non-null fields?
- Can service tombstones or DELETED volume-instance metadata remain queryable indefinitely after the actual resources have been destroyed?
- For a volume marked isPendingDeletion:true, does a future deletedAt represent the recovery/purge deadline? Does the documented 48-hour recovery period imply any guarantee about when API metadata disappears?
- What supported read-only checks verify zero running instances and permanent storage destruction, and is storage billable while deletion is pending?
The goal is a conservative cleanup verifier that never treats an authorization error, incomplete listing or temporary API failure as successful deletion. An official documentation reference or response example would be very helpful.
This is a generic API-contract question. No project identifiers, private logs, credentials or application data are included. Thank you.
2 Replies
8 hours ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 8 hours ago
7 hours ago
Hey — API-contract only, from public docs. Gaps called out so a verifier doesn’t false-succeed.
Documented deletes:
- Service: “delete the service and all its deployments” (https://docs.railway.com/integrations/api/manage-services)
-
- Volume: “permanently delete the volume and all its data” (https://docs.railway.com/integrations/api/manage-volumes)
Volumes are queued and permanently deleted within 48 hours; restore via the email link until then (https://docs.railway.com/volumes/reference). Mutation success ≠ storage already gone.
Errors (https://docs.railway.com/integrations/api): GraphQL often returns HTTP 200 with an errors array, including Not Authorized. Always inspect errors. Not Authorized / 429 / 5xx is not proof of deletion. There is no documented dedicated “permanently absent” code for serviceInstance / volumeInstance.
Verify with authorized parent lists, not a guessed by-id not-found:
- Record projectId, serviceId, volumeId.
- Delete; require data success AND errors empty.
- Re-list with the same token. Parent project list must still work. Service id absent from project services → service delete accepted. Volume may still appear while queued — treat as NOT permanently gone.
- After the 48h window, list again. Absent + authorized list succeeds → treat as permanently gone. Still listed → not permanent yet.
- Any Not Authorized / 429 / wrong-environment empty list → fail closed.
Direct answers:
- Exact permanent-absence payload? Not documented. Use authorized lists showing the id absent.
- Can metadata linger? Volumes yes, up to 48h. API tombstone lifetime after purge is undocumented.
- isPendingDeletion / deletedAt vs 48h? Product docs define the 48-hour restore window, not those field contracts.
- Zero instances + storage destroyed? List services/deployments/volumes. Billing during pending deletion is not clearly guaranteed.
Introspect the live schema at GraphiQL as the API docs recommend — don’t invent field semantics.
3 hours ago
Follow-up with a concrete disposable restore-drill case. Please confirm only; do not restore, reattach, restart, or modify resources.
Project: be60efdc-97b5-4e35-bc0a-fa6a02d07f1b
Volume: 8d88f9d8-cd4a-4dfd-a837-5d84a995465f
VolumeInstance: b7ec0bbd-ca62-4cf6-a405-a3decaf10fcb
deletedAt: 2026-09-11T23:58:55.331Z
Authenticated observation after 48 hours: 2026-09-13T23:59:23.532Z
The volume is absent from the complete project volume listing. The direct VolumeInstance lookup still returns state=DELETED, isPendingDeletion=false, serviceId=null. The scratch service is absent; its deployment reports REMOVED and stopped. No credentials or customer data are included here.
The community reply above explicitly notes that tombstone lifetime after purge is undocumented. Could Railway confirm whether this exact instance is only retained metadata after permanent storage deletion, and which supported evidence establishes that the underlying storage and recoverable copies are gone? We are not treating an authorization error or an incomplete list as absence. This is a provider API/storage lifecycle question, not application debugging. Thank you.