oxidecomputer / oxidecomputer/dropshot

Should dropshot endpoints be able to return `Option<T>`?

Open
#669 8 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
1.2k
Forks
104
Avg merge
1d 19h
Merged PRs (30d)
22

Description

Today, these two endpoints:

#[endpoint {
    method = GET,
    path = "/foo",
}]
async fn get_foo(_rqctx: RequestContext<()>) -> Result<HttpResponseOk<Foo>, HttpError> { .. }

#[endpoint {
    method = GET,
    path = "/option_foo",
}]
async fn get_option_foo(_rqctx: RequestContext<()>) -> Result<HttpResponseOk<Option<Foo>>, HttpError> { .. }

produce identical OpenAPI definitions:

    "/foo": {
      "get": {
        "operationId": "get_foo",
        "responses": {
          "200": {
            "description": "successful operation",
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "#/components/schemas/Foo"
                }
              }
            }
          },
          "4XX": {
            "$ref": "#/components/responses/Error"
          },
          "5XX": {
            "$ref": "#/components/responses/Error"
          }
        }
      }
    },
    "/option_foo": {
      "get": {
        "operationId": "get_option_foo",
        "responses": {
          "200": {
            "description": "successful operation",
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "#/components/schemas/Foo"
                }
              }
            }
          },
          "4XX": {
            "$ref": "#/components/responses/Error"
          },
          "5XX": {
            "$ref": "#/components/responses/Error"
          }
        }
      }
    }
  },

This is surprising/wrong, and causes generated clients to not realize that get_option_foo() might return None / null instead of a Foo. It's relatively easy to work around this by returning a struct that contains an Option. I don't know if returning an Option directly should work; if not, could we reject it at compile time somehow?

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing how endpoint return types are converted into OpenAPI response schemas, using the /foo and /option_foo examples as the comparison. Determine and test the intended behavior for direct Option returns, then verify that the generated schema reflects nullability or that unsupported returns are rejected at compile time.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
api, backend-api-design
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.