Bug Report: isLoading remains true even after stream completion due to delayed history fetch
Context
We are using stream.submit() from the LangGraph SDK to stream messages with streamMode: ["custom"]. During the streaming process, stream.isLoading is set to true — which is expected. However, it remains true even after streaming completes. This introduces unnecessary UI blocking and delays the feedback to the user.
Code snippet:
stream.submit(
{
messages: [...toolMessages, ...messages],
userId: user!.id,
currentBrandContextId: selectedBrandId,
},
{
streamMode: ["custom"],
optimisticValues: (prev) => ({
...prev,
messages: [...(prev.messages ?? []), ...toolMessages, ...messages],
}),
}
);
Expected Behavior
Once the streaming of response chunks is finished — i.e., the for await (const chunk of stream) equivalent is complete — we expect isLoading to be set to false.
Actual Behavior
What seems to be happening is:
stream.submit() starts the stream.
Streaming completes (we receive the final chunk).
Then, the SDK internally triggers a history fetch request (likely via refetch() or a similar method).
isLoading remains true until this secondary history call also completes.
As a result, the UI is blocked even after the streaming has concluded, leading to a delayed perception of responsiveness.
Why this matters
For most UI implementations, isLoading is interpreted as “stream in progress”.
Fetching history can be slower and shouldn’t block the streaming UX.
From a user’s perspective, the spinner or loading indicator persists longer than expected, creating confusion or perceived slowness.