last comment
⌘K
Anshuman Bhardwaj This is superb! Thanks for sharing the step by step guide here 🙌 Can't wait to try
Jonoroboto Tell us how you get on. One thing we haven’t figured out yet, that I would love to solve, is agent orchestration with git worktrees and how best to fire something off like that in one go. Think a less destructive Gastown, that you’d be comfortable throwing at a production repo. This is a simplified workflow, but should give you the idea.
Pauline P. Narvas The NS_BASE_STREAM_CLOSED error typically occurs when the MCP client connection is closed prematurely. When you're using MCP tools with streaming, the client needs to stay open until the entire response completes, if it closes early, you'll hit this error. Here's what I'd recommend checking: Make sure your MCP client isn't timing out or disconnecting before the stream finishes Verify that your connection handling code keeps the client alive throughout the entire streaming response Check if there are any timeout settings that might be causing the connection to close early Let me know if you hav
phanithlim Thanks Pauline P. Narvas for the response! I’ve been stuck on this for about 3 days now and still can't resolve it. I was previously using experimental_createMCPClient, and it worked perfectly. However, since I updated my code to use the standard createMCPClient, I began facing the NS_BASE_STREAM_CLOSED issue mentioned above. The connection seems to drop the moment the LLM starts streaming the tool output back to the UI. Since I am using streamText with toUIMessageStreamResponse(), I suspect the new createMCPClient handles transport lifecycles differently, causing it to be garbage collected or
Swarnava Sengupta With 106M ISR writes vs 30M ISR reads, your write-to-read ratio is unusually high (about 3.5:1). This typically indicates one or more of these issues: Very short revalidation intervals – If your revalidate value is too low (e.g., 10-30 seconds), pages regenerate frequently even if content hasn't changed Excessive on-demand revalidation calls – If your backend triggers revalidatePath() or revalidateTag() too aggressively on every content update Bot/crawler traffic triggering regenerations – Bots hitting many unique URLs can cause cache misses that trigger new page generations Large number of un
Akash Electron thank you @swarnava
Jacob Paris How are you injecting the cookie? Can you add it in a request interceptor instead so it resolves at request time instead of ahead of time?
Bharathrnair7 1528 async function processQueue(newAccessToken?: string, error?: any) { while (requestQueue.length) { const queued = requestQueue.shift(); if (!queued) continue; if (error) { queued.reject(error); } else { try { // Explicitly set the new token on the queued request config // instead of relying on the interceptor (which reads stale cookies) if (newAccessToken) { queued.config.headers = { ...queued.config.headers, Authorization: \Bearer ${newAccessToken}\, }; } const response = await http(queued.config); queued.resolve(response); } catch (err) { queued.reject(err); } } } } try { const newAccessToken
Pauline P. Narvas Spot on! Your assumption is exactly right. :D Since that Hero component with revalidate is shared across your generateStaticParams pages, each one of those 1,350+ pages effectively "inherits" its own ISR schedule. This means that after the 1-week window, a visit to any page will kick off a background regeneration. If your traffic hits all those pages, you're looking at a huge spike in serverless executions which is definitely why you're seeing those limits pop up! A couple ways we can optimize this: Fetch client-side: This is the most straightforward path. If you move the GitHub stars fetch to
Juan D. Martinez I was thinking of going client side or creating a dedicated landing page for this hero section. I'm not a big fan of client fetching on stuff that doesn't change often, but haven't thought of that API apporach you mentioned, guess I'll try that one instead. I appreciate the help @pawlean 🙌🏻
Pauline P. Narvas No worries, Juan! 😃 Come back with updates - excited to hear how you get on 🙂
