Merging internal commits for release/8.0

[vseanreesermsft]

No description provided.

[Copilot]

Pull request overview

This PR merges internal changes intended for the release/8.0 line, including updates to SignalR message buffering/backpressure cancellation behavior and routine dependency/version roll-forward.

Changes:

• Adjusted stateful reconnect CloseMessage write cancellation behavior in HubConnectionContext.
• Added/updated tests covering buffered backpressure cancellation and a new close scenario in SignalR handler tests.
• Updated dependency versions (8.0.25 → 8.0.26, plus related servicing builds) and refreshed dependency-flow NuGet sources.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/SignalR/server/SignalR/test/Internal/MessageBufferTests.cs	Adds tests for buffered backpressure default cancellation and explicit cancellation; renames an existing backpressure test.
src/SignalR/server/SignalR/test/HubConnectionHandlerTests.cs	Extends the close scenarios and test flow to cover a backpressure-timeout close path.
src/SignalR/server/Core/src/HubConnectionContext.cs	Changes CloseMessage cancellation token selection for stateful reconnect writes.
src/SignalR/common/Shared/MessageBuffer.cs	Introduces a TimeProvider-backed 5s timeout for buffered backpressure waits and adjusts timer initialization.
eng/Versions.props	Rolls forward runtime/EFCore/package versions to 8.0.26 servicing set.
eng/Version.Details.xml	Updates dependency versions and SHAs to align with the new runtime/EFCore inputs.
NuGet.config	Adds new dependency-flow package sources and enables them in disabledPackageSources.

Comments suppressed due to low confidence (1)

src/SignalR/common/Shared/MessageBuffer.cs:181

• WriteAsyncCore only applies the internal 5-second CancellationTokenSource while waiting for buffered backpressure (_waitForAck). If the caller passes a non-cancelable token (e.g., CancellationToken.None for CloseMessage) and the write blocks on pipe backpressure, _writer.WriteAsync(messageBytes, cancellationToken) can hang indefinitely. Consider ensuring the token passed to _writer.WriteAsync is always cancelable (e.g., link in an internal timeout when the provided token can't be canceled), not just for the ack-wait path.

    private async ValueTask<FlushResult> WriteAsyncCore(Type hubMessageType, ReadOnlyMemory<byte> messageBytes, CancellationToken cancellationToken)
    {
        // TODO: Add backpressure based on message count
        if (_bufferedByteCount > _bufferLimit)
        {
#if NET
            using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(5), _timeProvider);
#else
            using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(5));
#endif
            using var _ = CancellationTokenUtils.CreateLinkedToken(cts.Token, cancellationToken, out var linkedToken);
            // primitive backpressure if buffer is full
            while (await _waitForAck.Reader.WaitToReadAsync(linkedToken).ConfigureAwait(false))
            {
                if (_waitForAck.Reader.TryRead(out var count) && count < _bufferLimit)
                {
                    break;
                }
            }
        }

        // Avoid condition where last Ack position is the position we're currently writing into the buffer
        // If we wrote messages around the entire buffer before another Ack arrived we would end up reading the Ack position and writing over a buffered message
        _waitForAck.Reader.TryRead(out _);

        // TODO: We could consider buffering messages until they hit backpressure in the case when the connection is down
        await _resend.Task.ConfigureAwait(false);

        // Await the flush outside of the _writeLock so AckAsync can make forward progress if there is backpressure.
        // Multiple flush calls is fine, it's multiple GetMemory calls that are problematic, which is fine since we lock around the actual write
        ValueTask<FlushResult> writeTask;

        await _writeLock.WaitAsync(cancellationToken: default).ConfigureAwait(false);
        try
        {
            if (typeof(HubInvocationMessage).IsAssignableFrom(hubMessageType))
            {
                _totalMessageCount++;
                _bufferedByteCount += messageBytes.Length;
                _buffer.AddMessage(messageBytes, _totalMessageCount, _pool);

                writeTask = _writer.WriteAsync(messageBytes, cancellationToken);
            }
            else
            {
                // Non-ackable message, don't add to buffer
                writeTask = _writer.WriteAsync(messageBytes, cancellationToken);
            }

[wtgodbe]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[wtgodbe]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).