datumctl edit truncates server validation errors and skips re-open-with-error flow

[kevwilliams]

Summary

When the API server rejects an edit with a Status of reason: Invalid (HTTP 422), datumctl edit prints only the leading prefix of status.message and drops the field-level detail that follows the first colon. It also does not reopen the editor with the error injected as #-prefixed comments the way upstream kubectl edit does — it instead aborts with Edit cancelled, no valid changes were saved.

This makes immutability and validation failures look like generic "is invalid" errors with no indication of what's wrong.

Reproduction

Edit any immutable field on a BillingAccountBinding (the entire spec is immutable):

datumctl edit billingaccountbindings -n organization-<org> \
  --organization <org> <binding-name> -v 8

In the editor, change spec.projectRef.name to something else and save.

Observed

The server returns a full Status object (visible at -v 8):

{
  "kind":"Status",
  "apiVersion":"v1",
  "status":"Failure",
  "message":"BillingAccountBinding.billing.miloapis.com \"the-other-org-l5ux2o-again-fm1olj\" is invalid: spec: Invalid value: \"object\": spec is immutable",
  "reason":"Invalid",
  "details":{
    "name":"the-other-org-l5ux2o-again-fm1olj",
    "group":"billing.miloapis.com",
    "kind":"BillingAccountBinding",
    "causes":[{
      "reason":"FieldValueInvalid",
      "message":"Invalid value: \"object\": spec is immutable",
      "field":"spec"
    }]
  },
  "code":422
}

…but datumctl prints only:

error: billingaccountbindings.billing.miloapis.com "the-other-org-l5ux2o-again-fm1olj" is invalid
A copy of your changes has been stored to "/tmp/datumctl-edit-XXXXXX.yaml"
error: Edit cancelled, no valid changes were saved.

The substring : spec: Invalid value: \"object\": spec is immutable is dropped, and the editor is not re-opened with the error as comments.

Expected

Match upstream kubectl edit behavior:

1. Print the full status.message (including the post-colon detail and the field from causes[]).
2. Reopen the editor with the error injected at the top as #-prefixed comments so the user can correct and retry without losing their edits.

For comparison, kubectl edit against the same resource prints:

error: BillingAccountBinding.billing.miloapis.com "..." is invalid: spec: Invalid value: "object": spec is immutable

…and reopens the file with the validation error commented in.

Environment

• `datumctl` version: (TBD — `datumctl version`)
• Cluster: `api.staging.env.datum.net`
• Verbosity used to capture full response: `-v 8`

Impact

Users cannot tell why an edit was rejected without re-running with `-v 8` and reading the response body manually. For resources with multiple validation rules (immutability, webhook checks, CRD XValidation), this makes the tool nearly unusable for self-service troubleshooting.

[gianarb]

I think the first question I have here is, how does it work for kubernetes and kubectl? Did we have lost some reporting code that makes this easier or are we trying to improve error reporting compared to kubectl?