Skip to content

feat: add x-ogen-raw-response flag to yield full control#1522

Merged
ernado merged 3 commits intoogen-go:mainfrom
jvatic:raw_response
Sep 18, 2025
Merged

feat: add x-ogen-raw-response flag to yield full control#1522
ernado merged 3 commits intoogen-go:mainfrom
jvatic:raw_response

Conversation

@jvatic
Copy link
Contributor

@jvatic jvatic commented Sep 5, 2025

This is a workaround for #1375 that allows working with SSE streams outside of the generated client code.

I'm not sure if it'd be appropriate to add an SSE implementation at this time, since there currently isn't an agreed upon standard for how to interpret OpenAPI schemas for text/event-stream responses and there's lots of different ways people are constructing them. I did think of providing a basic wrapper around the exposed http.Response that implements the SSE protocol and could be updated later to handle decoding event data, but there's already established libraries out there that can do the job (albeit most of them do expect to own the request and response, not just the response, so not as straight forward as it could be).

By adding x-ogen-raw-response: true to each text/event-stream response, this patch will cause ogen to expose the raw http.Response without first reading it's body, e.g.:

"text/event-stream": {
    "schema": {
        "items": {
            "$ref": "#/components/schemas/MyEvent"
        },
        "type": "array"
    },
    "x-ogen-raw-response": true
}

(this is just one example of how you might represent an SSE stream.)

This flag will also change server code-gen to give full control over the handler (I've separated these handlers into a new interface since the Client's methods don't match the handler signatures for raw requests).

One can also add an application/json response with the same schema to generate encoders/decoders for it (I'd recommend doing this in a patch script, which I find myself reaching for with most OpenAPI schemas I encounter anyways).

Now when we call our generated client method, we'll get something like this back:

type SuscribeToEventsOKRawTextEventStream struct {
	Response *http.Response `json:"-"`
}

Which we can then pass into our SSE reader of choice to stream the events.

This is most useful when also enabling request editing features:

generator:
  features:
    enable:
      - "paths/client"
      - "client/request/options"
      - "client/editors"

We'd pass an option to either our client construction or the request method that sets the appropriate headers, e.g.:

req.Header.Set("Cache-Control", "no-cache")
req.Header.Set("Accept", "text/event-stream")
req.Header.Set("Connection", "keep-alive")

@jvatic jvatic force-pushed the raw_response branch 2 times, most recently from 5118df0 to f3e67c6 Compare September 5, 2025 21:23
@ernado
Copy link
Member

ernado commented Sep 17, 2025

Hi, thank you for your contribution.
Plese resolve conflicts so we can merge this.

@ernado
Copy link
Member

ernado commented Sep 17, 2025

Also, some opinionated SSE implementation can be added to ogen disregarding consensus in OpenAPI.

@jvatic
Copy link
Contributor Author

jvatic commented Sep 17, 2025

Great, thanks @ernado! I've rebased against main and resolved the conflict, but this has caused the check-generate lint to fail (probably a cache issue?—the files it's complaining about are added in this PR).

@ernado ernado merged commit f0fb940 into ogen-go:main Sep 18, 2025
14 checks passed
@jvatic jvatic deleted the raw_response branch September 18, 2025 01:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants