run_with_streaming_response and automatically streaming buffered responses #967

Activity

1. bnusunny commented on Mar 12, 2025

   

   bnusunny

   on Mar 12, 2025

   Collaborator

   More actions

   I'm not quite understand your use case. Do you mind to share a sample code?
2. keichan34 commented on Mar 13, 2025

   

   keichan34

   on Mar 13, 2025

   Author

   More actions

   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.

   👍React with 👍1Reacted by Jess Izen
3. bnusunny commented on Mar 15, 2025

   

   bnusunny

   on Mar 15, 2025

   Last edited by bnusunny

   Collaborator

   More actions

   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

   on Mar 22, 2026

   More actions

   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.

   👍React with 👍1Reacted by Jess Izen
5. keichan34 commented on Mar 23, 2026

   

   keichan34

   on Mar 23, 2026

   Author

   More actions

   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.

   👍React with 👍1Reacted by Jess Izen
6. keichan34

   closed this as completedon Mar 23, 2026
7. github-actions commented on Mar 23, 2026

   

   github-actionsbot

   on Mar 23, 2026 – with GitHub Actions

   More 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.
8. ndaba1

   added a commit that references this issue on Sep 9, 2026

   fix(aws): an empty body is a buffered reply, not a sentinel byte

   ...

   0343353