Summary
When looking up a resource by ID via endpoints like instance_view, supplying a project query parameter alongside the ID returns:
> oxide instance view --instance 609ff898-3d41-43ad-a897-3ce1033d89b7 --project brandon
error
Error Response: status: 400 Bad Request; headers: {"content-type": "application/json", "x-request-id": "27d1a768-7faf-490e-a438-031ed20647cd", "content-length": "173", "date": "Fri, 29 May 2026 20:18:50 GMT"}; value: Error { error_code: Some("InvalidRequest"), message: "when providing instance as an ID project should not be specified", request_id: "27d1a768-7faf-490e-a438-031ed20647cd" }
Since UUIDs are globally unique, the project argument is redundant, but not wrong. Rejecting the request creates friction for callers (CLI, scripts, UI code) that already have a project handle and pass it along uniformly regardless of whether the resource is identified by name or ID. This is surprising when writing the code that supplying both fails the request and requires a runtime error when testing to identify (I didn't see it in any docs).
If oxidecomputer/oxide.rs#714 is implemented, it would need to handle these situations (omitting project when ID is used), so IMO it would be best to handle this in the API layer.
Supplying both project and id could provide a slight safe-guard against using the wrong ID (i.e. wrong copied ID).
Proposed behavior
Two reasonable options:
- Ignore the project when an ID is supplied — treat it as redundant client-side info.
- Validate that the project matches the resolved resource's actual project; return 404 if not.
I'd lean towards option 2 since that provides the additional safe-guard against ID-to-project mismatches.
Summary
When looking up a resource by ID via endpoints like instance_view, supplying a project query parameter alongside the ID returns:
Since UUIDs are globally unique, the project argument is redundant, but not wrong. Rejecting the request creates friction for callers (CLI, scripts, UI code) that already have a project handle and pass it along uniformly regardless of whether the resource is identified by name or ID. This is surprising when writing the code that supplying both fails the request and requires a runtime error when testing to identify (I didn't see it in any docs).
If oxidecomputer/oxide.rs#714 is implemented, it would need to handle these situations (omitting project when ID is used), so IMO it would be best to handle this in the API layer.
Supplying both project and id could provide a slight safe-guard against using the wrong ID (i.e. wrong copied ID).
Proposed behavior
Two reasonable options:
I'd lean towards option 2 since that provides the additional safe-guard against ID-to-project mismatches.