In a Laravel streamed response, why do session writes inside the stream callback get lost, and what happens to an exception thrown there?

## Where the callback sits in the request Laravel's front controller ends with one call, `$app->handleRequest(Request::capture())`, and `Application::handleRequest()` is three lines: 1. `$response = $kernel->handle($request)` runs global middleware, the router, route middleware and the controller, and returns a response object. 2. `->send()` writes status, headers and body to the client. 3. `$kernel->terminate($request, $response)` runs terminable middleware and terminating callbacks. For an ordinary response the body already exists after step 1. For a `StreamedResponse` the body is a **callback that runs in step 2**. By then every middleware has finished its "after" part. The general boot sequence is the lifecycle's subject; here what matters is the consequences for streams. ## Consequence 1: session writes are lost `Illuminate\Session\Middleware\StartSession` handles a request like this: - start the session and attach it to the request; - `$response = $next($request)`, which reaches the controller that returns the `StreamedResponse`; - store the current URL, add the session cookie to the response; - **`saveSession()`**, writing the session to its driver; - return the response. Only afterwards does `send()` run your callback. So in a sales export: ```php return response()->streamDownload(function () { // ... write a million rows ... session()->flash('status', 'Export finished'); // never saved }, 'sales.csv'); ``` the flash message changes the in-memory session after it was persisted, and it is gone. The same applies to `Cookie::queue()` inside the callback: the queue middleware already copied cookies onto the response, and the headers are already sent anyway. Fixes: - Write session state **before** returning the response, if it does not depend on the export's result. - Record results that are only known at the end somewhere durable, such as an `exports` table row or a cache key, and let the next page read it. ## Consequence 2: exceptions cannot become error pages The exception handler normally turns an exception into a response inside `handle()`. An exception in a stream callback happens after that, and after the status line (`200`) and headers were written. Laravel's streaming helpers each deal with this: | Helper | On an exception in your code | |---|---| | `streamDownload()` | rethrown as `StreamedResponseException`; the uncaught-exception handler reports it, and its `render()` returns an empty `Response`, so no error HTML lands in the file | | `eventStream()` | caught inside the stream and passed to `report()`; the loop ends and the `</stream>` end marker is **not** sent | | `stream()` | no wrapper; the exception escapes `send()`, is reported by the global handler, and an error page may be written after the partial body | In every case the client sees a 200 with a body that stops early. That makes these practices important: 1. Validate inputs, check authorization and run the first query **before** returning the streamed response, so predictable failures still produce proper 4xx or 5xx responses. 2. Wrap risky work inside a plain `stream()` callback in `try`/`catch`, and `report()` the error yourself. 3. Give consumers a way to detect truncation: a final marker row, a row count, or an end event. ## Other things that are already done by the time the callback runs - Authentication and authorization middleware have run, which is correct, but a policy check done lazily inside the callback can no longer return a 403. - Response-modifying middleware, such as ones that add headers after `$next()`, have already acted on the empty streamed response object. - Terminable middleware and `terminating()` callbacks run only after the stream completes, so they can be delayed by minutes. ## How to test for it A feature test that calls the export route can read the streamed body with the test response's streamed-content helper and then assert on the session and database. Asserting that the flash message is **absent** documents the pitfall for the next developer, and asserting that the `exports` row is marked finished proves the durable path works. For error handling, make the query throw inside the callback and assert that the exception was reported rather than rendered into the body. ## What a senior answer shows Placing the callback correctly (inside `send()`, after `handle()` and before `terminate()`), naming `StartSession::saveSession()` as the reason session writes vanish, and describing each helper's error path, including the missing end marker for `eventStream()`.