oxidecomputer / oxidecomputer/omicron
API: Distinguish between internal/external resources, especially in the context of errors
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 572
- Forks
- 97
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 96
Description
Context: https://github.com/oxidecomputer/omicron/pull/457#discussion_r766252951
The external::Error type references a ResourceType enum. This enum is a necessary part of certain errors, such as "Not found".
Although expressive and useful for externally-facing APIs, this unfortunately has resulted in a conflated resource type for internally-facing APIs.
We should figure out a way to use these expressive error types while separating the notion of an "internally visible" and "externally visible" resource.
(As a concrete example: "Disks" and "Instances" are externally-facing resources. "SagaDbg", "DownloadArtifact", "MetricProducer" are all internally-facing)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the linked pull request discussion, then inspect the external::Error type and its ResourceType enum. Define and implement a separation between externally visible resources such as Disks and Instances and internal resources such as SagaDbg, DownloadArtifact, and MetricProducer, while preserving expressive API errors.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- api, backend-api-design
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100