Nullable response have a weird behavior right now

[timotheeguerin]

import "@typespec/http";

using TypeSpec.Http;

@error
model Error {
  message: string;
}

@route("/1") op read1(): string | null;
@route("/2") op read3(): string | null | Error;

Playground link

Resulting is a 204 no content before PR #355 which remove ignore null responses.

Feel like it should be making the string body nullable

[mikekistler]

I agree with @timotheeguerin that a return type of string | null should result in a response schema:

    "schema": {
      "type": "string",
      "nullable": true
    }

[timotheeguerin]

• null present in op return union means each response is nullable?

[nguerrera]

Asking for re-triaqge here. As soon as someone mentions the word "null" in a meeting, we go down a rabbit hole and it is harder to dig out of it when our own code doesn't actually interpret "null" as it should in some cases.

[timotheeguerin]

Current state of this issue is we do produce the right(expected) responses but the body is not marked as nullable: true

[clhodapp]

Currently, the OpenAPI emitter wraps trivial nullability in an unnecessary oneOf. That is to say, if you write a type of string | null, you'll get a nullable one-child oneOf, where the only child is string.