We are testing an isolated fork of a stopped Machine’s encrypted 1 GB volume in lhr through
POST /v1/apps/{app_name}/volumes. The request returned HTTP 400. Our diagnostic wrapper
unfortunately retained only the status, request ID, response length and hash, not the error text;
a local correction is tested. We have not retried the consumed request.
This is the request shape, with resource names, IDs and image references replaced by placeholders:
{
"name": "example_fork",
"region": "lhr",
"size_gb": 1,
"encrypted": true,
"source_volume_id": "SOURCE_VOLUME_ID",
"auto_backup_enabled": false,
"compute": {"cpu_kind": "shared", "cpus": 1, "memory_mb": 256},
"compute_image": "DESTINATION_IMAGE_REFERENCE",
"require_unique_zone": true,
"unique_zone_app_wide": false
}
The public flyctl volumes fork implementation leaves size, encryption and automatic-backup
fields null and selects the attached source Machine’s image. Our request supplies explicit values
and the intended destination image. We have not established that these differences caused the 400.
Are those explicit fields supported together with source_volume_id? Can compute_image describe
the intended destination image? Is there a documented validation rule or a self-service way to
recover an earlier Machines API error message by request ID, without repeating the create operation?
We can provide the exact request ID privately through an appropriate Fly channel if staff need it.
We are not requesting any resource creation, modification or deletion.
maybe the size_gb you are providing in the request is smaller than the source volume, or there is a typo in the source_volume_id.