Repository navigation
run_with_streaming_response and automatically streaming buffered responses #967
Description
Activity
I'm not quite understand your use case. Do you mind to share a sample code?
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.
Reacted by Jess IzenGot it! It will be useful to able to use response streaming mode to process both buffered and streaming functions. PR is welcome.
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_responsewith buffered handlers (Body::Text) on a Function URL configured withRESPONSE_STREAMinvoke mode, using the currentmainbranch.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 200The 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_reqchannel) 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.
Reacted by Jess IzenI 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.
Reacted by Jess IzenThis 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.- added a commit that references this issue
on Sep 9, 2026
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?