Teams stream timeout when streaming a message

[VallaeysNathan]

When performing long running operations i want to send text chunks in the stream to keep a status update. like in the following line of code.
turnContext?.StreamingResponse.QueueTextChunk($"Message for {user.Key}: {message}");

But it seems that this does not make the stream timeout extend. This means that messages that take quite a while to fully stream just get cut in half because teams seem to close the stream.

Is there any way to handle this using the SDK?

[tracyboehrer]

Using QueueTextChunk is probably not what you'd want to do. This would just keep adding text to the accumulated text. Though I don't know why that wouldn't work as StreamResponses will send new chunks at a regular interval.

I would try to periodically call QueueInformativeUpdateAsync instead.

[VallaeysNathan]

I have also tried that but that did not seem to keep the stream open any longer and resulted in this message in teams after the timeout.

I could also be missing something here...

[tracyboehrer]

I haven't personally seen this. But can't say I've tested for something very long running. We can setup a test to see if there is anything to do about it.

[VallaeysNathan]

it usually happens after a couple of minutes. My guess is that this is due to strict timeouts purely from teams because no matter what is send to teams it doesn't seem to be extending the amount of time there is to send the final message.

This then combined with a previous issue i made (link) makes it so this is quite hard to handle.

For this specific instance i managed to work around it but it might be something worth looking into.

[tracyboehrer]

@VallaeysNathan Thanks! We will definitely look into it. Teams will report error is certain cases and we respond accordingly when we can. This could be another.

[sw-joelmut]

Hi @VallaeysNathan and @tracyboehrer,

I managed to reproduce this issue in JS and while testing I've found that the error received from MS Teams has a limit of 2 minutes to complete the streaming activity (source).

I did a small test to simulate that every approximately 2 minutes, send a new activity, and delete the previous one. What I've noticed is that the user experience is not great, since you will clearly see removing and adding activities every 2 minutes.
Also, I tried using 'updateActivity' but couldn't make it work.

Regarding this MS Teams behavior, we have an issue in JS microsoft/Agents-for-js#649, to default to non-streaming when any of these kinds of errors happen.

Apparently .NET already handle this error and default to non-streaming, is this correct, Tracy?

Agents-for-net/src/libraries/Builder/Microsoft.Agents.Builder/StreamingResponse.cs

Line 633 in 20c18ad

if (TeamsStreamCancelled.Equals(errorResponse?.Body?.Error?.Code, StringComparison.OrdinalIgnoreCase))

[tracyboehrer]

There is a case in DotNet where it would start out streaming, then downgrade to non-streaming. I'm not sure if this would also be appropriate in this case. It sounds like Teams just closes the stream, so I'm not sure what the user experience will look like. Worth a try.

[bryansusu]

We're experiencing the same issue. After investigating, we learned from the Microsoft team that:

1. LongRunningMessages in TeamsAgentApplicationOptions is deprecated/no-op (kept only for backward compatibility from Teams AI SDK v1)
2. The 2-minute streaming timeout is enforced by Teams itself, not the SDK

Question for the team:

Is it possible to implement a "chunked streaming" pattern where we:

1. Detect when approaching the ~2 minute limit (e.g., at 1:45)
2. Gracefully end the current stream with EndStreamAsync()
3. Start a new stream for the remaining content

Would this work, or does Teams only allow one streaming response per user message?

If a single stream per message is enforced, would falling back to regular SendActivityAsync() messages after ending the stream be a viable workaround?

// Pseudocode concept
if (elapsedTime > TimeSpan.FromMinutes(1.75))
{
    await turnContext.StreamingResponse.EndStreamAsync(cancellationToken);
    // Can we start a new stream here, or send regular messages?
    await turnContext.SendActivityAsync(MessageFactory.Text(remainingContent), cancellationToken);
}

[VallaeysNathan]

@bryansusu I experimented with restarting the stream but that always just opened a new streaming message to teams for me which resulted in the user having 2 separate incomplete messages. Right now i use a fallback to SendActivityAsync making it so the user still has 2 messages but the last one sent with SendActivityAsync is complete.

On older versions of the sdk it was hard to check if the stream was ended but this issue fixed that and i think that is now included in the newest versions of the sdk.

Maybe another possible alternative is detecting when the stream is about to close (e.g., at 1:45) and then closing the stream with a FinalMessage along the lines of "your response will be sent shortly" and then using SendActivityAsync to send the response once ready.

[bryansusu]

Workaround: Using ResetAsync() to bypass the 2-minute Teams streaming limit

We found a workaround using StreamingResponse.ResetAsync(). This method internally calls EndStreamAsync() and resets the state, allowing you to continue streaming in a "new" stream.

Approach

1. Set up a repeating timer that fires before the 2-minute limit (e.g., at 1:50)
2. When timer fires: queue a continuation message, call ResetAsync(), clear the Message property
3. Continue streaming - the timer repeats for each new stream segment

Important: Clear the Message Property

After calling ResetAsync(), you must set the Message property to an empty string. Otherwise, the accumulated message content gets sent again, causing duplicate text in Teams.

The Message property has a private setter, so reflection is required:

// One-time setup: get the Message property via reflection
var streamingResponseType = typeof(TurnContext).Assembly
    .GetType("Microsoft.Agents.Builder.StreamingResponse");
var messageProperty = streamingResponseType?.GetProperty("Message", BindingFlags.Public | BindingFlags.Instance);

// After ResetAsync, clear the Message
messageProperty?.SetValue(_turnContext.StreamingResponse, "");

Full Pseudo Code

// Setup: repeating timer
_timeoutTimer = new Timer(
    OnTimeoutTimerElapsed,
    null,
    TimeSpan.FromSeconds(110),   // First fire at 1:50
    TimeSpan.FromSeconds(110));  // Repeat for new streams

// Timeout handler
private async Task HandleTimeoutAsync()
{
    // Check if there's any content in the current stream
    var hasContent = !string.IsNullOrEmpty(_turnContext.StreamingResponse.Message);

    // Only show timeout message if stream is empty (nothing visible to user yet)
    // If content exists, silently continue in new message
    if (!hasContent)
    {
        _turnContext.StreamingResponse.QueueTextChunk("*Continuing response in new message...*");
    }

    // Reset the stream (calls EndStreamAsync internally)
    await _turnContext.StreamingResponse.ResetAsync(cancellationToken);

    // IMPORTANT: Clear Message to avoid duplicate content!
    // (requires reflection since setter is internal)
    messageProperty?.SetValue(_turnContext.StreamingResponse, "");
}

This allows theoretically unlimited streaming duration. Works in production for us!

[tracyboehrer]

@bryansusu Clever. It probably won't happen prior to the holidays, but if we can detect it, we should be able to do something similar just automatically. Or just internalize that same thing. We'll take a look.

[MattB-msft]

You could just send an update using the StreamingResponse.QueueInformativeUpdateAsync(...). which will keep the stream alive and allow you to send a meaningful informational update to the user w/out adding to the body.
is there some reason this pattern is not appropriate for you ?