RevalidateTag During Streaming Route Handler Response Is Silently Dropped

In app-route handlers, pending revalidations are resolved exactly once when the handler returns (resolvePendingRevalidations -> executeRevalidates). The app-route template reads pendingWaitUntil only immediately after; any revalidation queued later (e.g., during streamed body) remains in workStore.pendingRevalidatedTags/paths and is never consumed.

1. pnpm install && pnpm build && pnpm start 2. Load / twice, timestamp stays same from cached 'demo' tag. 3. curl -X POST localhost:3000/api/stream (streaming route calls revalidateTag('demo','max') after 100ms, before stream closes). 4. Reload / - timestamp never changes. 5. Control: curl -X POST localhost:3000/api/direct (non-streaming) reload / twice and timestamp changes.

Wrapping the response body with a new ReadableStream may alter Content-Length handling and could interact with HTTP pipelining or compression; test with proxies and CDNs. If the stream is cancelled before close, the cancel handler attempts to run revalidations, but if the underlying work was incomplete this may invalidate cache prematurely. Duplicate revalidations are unlikely because executeRevalidates clears the pending arrays, but verify on the target version. Rollback: replace the modified file with the original and rebuild. For extra safety, add a timeout/guard to avoid waiting too long for late revalidations after response close in high-latency streams.