Skip to content

run_with_streaming_response and automatically streaming buffered responses #967

Description

@keichan34

I know that right now, buffered responses will return an empty response when running with run_with_streaming_response (#805). Would it be possible (would PRs be accepted?) for some code that would intercept buffered responses and transform them to a dummy stream?

I'm currently doing this in my app because I'm sharing some error handling code between the buffered and streaming APIs, but I think it would make sense for something like this to live in the runtime. What do you think?

Activity

  1. bnusunny commented on Mar 12, 2025

    @bnusunny
    Collaborator

    I'm not quite understand your use case. Do you mind to share a sample code?

  2. keichan34 commented on Mar 13, 2025

    @keichan34
    Author

    It's basically exactly what's in #805. I've broken up my APIs in to two Lambda functions -- one for buffered and one for streaming, and I want to reuse buffered handlers between the streaming and buffered APIs.

  3. bnusunny commented on Mar 15, 2025

    @bnusunny
    Collaborator

    Got it! It will be useful to able to use response streaming mode to process both buffered and streaming functions. PR is welcome.

  4. fangkangmi commented on Mar 22, 2026

    @fangkangmi

    I investigated this to prepare a PR and wanted to share my findings.

    Reproduction attempt (March 2026)

    I deployed a minimal Lambda using run_with_streaming_response with buffered handlers (Body::Text) on a Function URL configured with RESPONSE_STREAM invoke mode, using the current main branch.

    async fn handler(event: Request) -> Result<Response<Body>, Error> {
        let path = event.uri().path();
        match path {
            "/buffered" => Ok(Response::builder()
                .status(StatusCode::OK)
                .header("content-type", "text/plain")
                .body(Body::Text("Hello from buffered handler!".to_string()))
                .unwrap()),
            _ => Ok(Response::builder()
                .status(StatusCode::OK)
                .body(Body::Text(format!("You requested: {}", path)))
                .unwrap()),
        }
    }
    
    #[tokio::main]
    async fn main() -> Result<(), Error> {
        run_with_streaming_response(service_fn(handler)).await
    }

    Result

    Both routes returned correct, non-empty responses through the streaming Function URL:

    $ curl https://<function-url>/buffered
    Hello from buffered handler!    # 28 bytes, HTTP 200
    
    $ curl https://<function-url>/hello
    You requested: /hello           # 21 bytes, HTTP 200
    

    The empty response problem from #805 no longer reproduces. It appears the Lambda platform has resolved the underlying issue since the original report (Feb 2024).

    What I verified in the code

    I also traced the full code path (BodyStream::poll_next → streaming protocol → EventCompletionRequest::into_req channel) and confirmed that buffered body data flows correctly through every layer.

    Question

    Can anyone still reproduce empty responses with the current version? If so, I'd like to know the specific setup (Function URL vs API Gateway, Axum router vs direct handler, runtime version, etc.) so I can target a fix.

  5. keichan34 commented on Mar 23, 2026

    @keichan34
    Author

    I was able to verify this using the latest lambda_http. Thanks! I'm not sure what PR exactly solved this, but this will make managing mixed streaming and buffered APIs much better. Thank you @fangkangmi for verifying on your side as well.

  6. github-actions commented on Mar 23, 2026

    @github-actions

    This issue is now closed. Comments on closed issues are hard for our team to see.
    If you need more assistance, please either tag a team member or open a new issue that references this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions