Fix AccessTokenCallback TNIR behavior and make SspiContextProvider mutually exclusive with token auth by cheenamalhotra · Pull Request #4520 · dotnet/SqlClient

cheenamalhotra · 2026-08-08T06:33:49Z

Follow-up to the review discussion on #4493, where it was noted that the TNIR behavior documented there does not actually apply when SqlConnection.AccessTokenCallback is used:

Since this is a fairly new introduction, we should fix it in our driver to match what happens in the AccessToken usecase. Documenting this would not be needed in that case.

The bug

On .NET Framework the driver disables Transparent Network IP Resolution by default whenever federated authentication is in use, unless the caller explicitly specified the TransparentNetworkIPResolution keyword. SqlConnectionInternal.ShouldDisableTnir only tested _accessTokenInBytes (SqlConnection.AccessToken) and ignored _accessTokenCallback (SqlConnection.AccessTokenCallback), so the two token-supplying APIs behaved differently for no good reason.

Investigating the fix surfaced a second, coupled defect in how the authentication setters build the connection pool key. Both are fixed here.

Changes

1. Single source of truth for "a token was supplied."
Added SqlConnectionInternal.IsAccessTokenProvided and used it in all three places that previously inlined the field checks — ShouldDisableTnir plus two spots in TdsParser.ConsumePreLoginHandshake. The duplicated hand-written expression is exactly what let these paths drift apart, and the existing @TODO in OnFedAuthInfo predicted this ("we're gonna forget one in one spot and cause a big ol bug someday").

The property's doc comment is deliberately scoped: it is the right check for prelogin FEDAUTHREQUIRED, server certificate validation and TNIR, but not for login feature-extension negotiation, which must keep testing the fields individually because _accessTokenCallback selects FedAuthLibrary.MSAL while _accessTokenInBytes selects FedAuthLibrary.SecurityToken. Calling that out prevents a future "cleanup" from collapsing those two sites and breaking fedauth login.

2. SspiContextProvider is now mutually exclusive with token authentication.
The AccessToken, AccessTokenCallback and SspiContextProvider setters each rebuilt the ConnectionPoolKey with the sibling authentication values hard-coded to null. Setting SspiContextProvider silently dropped a previously assigned access token or callback from the pool key, so it never reached the internal connection even though the public property still reported it as set — which would also have defeated the TNIR fix above.

SSPI is an alternative to token-based authentication rather than a complement to it, so the correct fix is not to preserve both but to reject the combination outright:

CheckAndThrowOnInvalidCombinationOfConnectionOptionAndAccessToken / ...AccessTokenCallback now throw if a context provider is already set.
New CheckAndThrowOnInvalidCombinationOfConnectionOptionAndSspiContextProvider, called from the SspiContextProvider setter, throws if either token property is already set.
Two new resource strings, one per direction, so the message names the property the caller actually set.

AccessToken and AccessTokenCallback were already mutually exclusive (validated in CheckAndThrowOnInvalidCombinationOfConnectionOptionAndAccessToken*), so that pairing was always benign; SspiContextProvider was the live defect.

The setters still pass the sibling values through when constructing the ConnectionPoolKey. With the new validation in place this is a no-op whenever a non-null value is assigned — the siblings are guaranteed null — so it matters only on the clearing path. Validation only runs when value != null (matching the existing convention in the token setters), so conn.AccessToken = "t"; conn.SspiContextProvider = null; is a clear, not a combination, and does not throw. Passing literal nulls there would wipe the token from the pool key while conn.AccessToken still reported it as set, which is the same class of bug this PR is fixing.

3. Tests.
ShouldDisableTnir is now internal static so the decision matrix can be unit tested directly (constructing a SqlConnectionInternal in a unit test is impractical). Added:

SqlConnectionOptionsTest.TestShouldDisableTnirWithCallerSuppliedToken (netfx only) — token/no-token x Azure/non-Azure endpoint x explicit/absent TNIR keyword.
ConnectionTests.SspiContextProviderAndAccessTokenStateAreMutuallyExclusive — all four assignment orderings across both token properties.
ConnectionTests.ClearingOneAuthPropertyPreservesTheOthersInPoolKey — pins the clearing-path behavior described above; verified to fail without the SqlConnection.cs change.
ConnectionTests.AccessTokenAndAccessTokenCallbackAreMutuallyExclusive — pins the pre-existing invariant that makes the token pairing safe.

Compatibility

The TNIR change is limited to .NET Framework, and only to connections using AccessTokenCallback, which now get the same TNIR default as AccessToken. Users who explicitly set TransparentNetworkIPResolution in the connection string are unaffected — the explicit keyword still takes precedence, so the escape hatch documented in #4493 continues to work.

The SSPI change is a deliberate behavior change on all targets: assigning SspiContextProvider alongside AccessToken/AccessTokenCallback now throws InvalidOperationException instead of silently producing an ambiguous authentication state. Any code relying on the old behavior was already broken — the token was being dropped from the pool key — so this converts silent misbehavior into a clear, actionable error. Clearing a property (assigning null) is unaffected and never throws.

Checklist

Tests added or updated
Public API changes documented (no public API surface changes)
Verified against customer repro (if applicable)
Ensure no breaking changes introduced — see the SSPI note under Compatibility: combining SSPI with token authentication now throws rather than silently dropping the token. Flagging explicitly for reviewer sign-off.

Suggested release note

Fixed SqlConnection.AccessTokenCallback not disabling Transparent Network IP Resolution by default on .NET Framework, making it consistent with SqlConnection.AccessToken. SqlConnection.SspiContextProvider is now correctly treated as mutually exclusive with AccessToken and AccessTokenCallback and throws when combined, instead of silently discarding the token from the connection pool key.

Notes for reviewers

Docs are intentionally untouched: docs: correct TransparentNetworkIPResolution behavior wording (Fixes #4489) #4493 already updates the TNIR wording to say TNIR is disabled when Entra ID auth or an access token is used, and this change makes that statement true for the callback path.
Targeted unit tests pass locally on net8.0, including the existing SspiTests suite; the net462 target builds clean but its tests cannot be executed on the macOS dev machine used here, so CI covers that leg.
Supersedes Fix AccessTokenCallback to match AccessToken behavior for TNIR and connection pool keys #4518, which was opened from a fork; this PR is branched directly in dotnet/SqlClient so the full CI/ADO pipeline suite runs.

On .NET Framework the driver disables Transparent Network IP Resolution by default whenever federated authentication is in use, unless the caller explicitly specified the TransparentNetworkIPResolution keyword. However, ShouldDisableTnir only tested _accessTokenInBytes (SqlConnection.AccessToken) and ignored _accessTokenCallback (SqlConnection.AccessTokenCallback), so the two token-supplying APIs behaved differently. Raised in review discussion on #4493. Changes: * Add SqlConnectionInternal.IsAccessTokenProvided, a single source of truth for "the caller supplied a token, either literally or via a callback", and use it in all three places that previously inlined the field checks (ShouldDisableTnir plus two spots in TdsParser.ConsumePreLoginHandshake). The duplicated, hand-written expression is what allowed the two paths to drift apart. * Fix the AccessToken, AccessTokenCallback and SspiContextProvider setters, which each rebuilt the ConnectionPoolKey with the sibling authentication values hard-coded to null. Setting SspiContextProvider silently dropped a previously assigned access token or callback from the pool key, so it never reached the internal connection even though the public property still reported it as set. These now preserve sibling state, matching the ConnectionString setter. (AccessToken and AccessTokenCallback are already mutually exclusive, so that pairing was benign; SspiContextProvider is not.) * Expose ShouldDisableTnir as internal static so it can be unit tested, and add coverage for the TNIR decision matrix and for pool-key preservation. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5368f578-219b-40a6-92a9-4742b56edbe6

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

Co-authored-by: Cheena Malhotra <13396919+cheenamalhotra@users.noreply.github.com>

Copilot

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR tightens behavior around federated authentication state by ensuring access-token state is consistently represented in connection pooling keys and by unifying “caller-supplied token” detection for TNIR and pre-login logic.

Changes:

Preserve AccessToken / AccessTokenCallback / SspiContextProvider in ConnectionPoolKey updates to avoid silently dropping authentication state.
Introduce SqlConnectionInternal.IsAccessTokenProvided and apply it in pre-login and certificate validation checks.
Add NETFRAMEWORK TNIR tests and simulated server tests covering token/callback state and mutual exclusivity.

Reviewed changes

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

Show a summary per file

File	Description
src/Microsoft.Data.SqlClient/tests/UnitTests/SimulatedServerTests/ConnectionTests.cs	Adds regression tests for pool-key preservation and token/callback mutual exclusivity.
src/Microsoft.Data.SqlClient/tests/UnitTests/Microsoft/Data/SqlClient/SqlConnectionOptionsTest.cs	Adds NETFRAMEWORK theory coverage for TNIR disablement with caller-supplied tokens.
src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/TdsParser.cs	Switches token detection to unified `IsAccessTokenProvided`.
src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/SqlConnection.cs	Updates pool-key rebuilds to preserve other auth-related properties.
src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/Connection/SqlConnectionInternal.cs	Adds `IsAccessTokenProvided` and refactors NETFRAMEWORK TNIR logic to accept it as an input.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

* Fully qualify the SqlConnection crefs on ShouldDisableTnir so they match the form already used on IsAccessTokenProvided. * Rename TestShouldDisableTnirWithAccessToken to TestShouldDisableTnirWithCallerSuppliedToken, since the parameter is isAccessTokenProvided and the case covers both AccessToken and AccessTokenCallback. * Assign a real non-null SspiContextProvider in the pool-key test instead of null, via a minimal TestSspiContextProvider stub, so the test matches its name and exercises the setter the way callers actually do. * Add SspiContextProviderIsPreservedInPoolKeyWhenAccessTokenStateIsSet, the reciprocal case: assigning a token must not drop a configured SspiContextProvider from the pool key. Both pool-key tests were verified to fail when the SqlConnection.cs fix is reverted. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5368f578-219b-40a6-92a9-4742b56edbe6

Copilot

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

codecov · 2026-08-10T18:11:36Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 62.66%. Comparing base (9b20e5e) to head (feb5e85).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4520      +/-   ##
==========================================
- Coverage   64.73%   62.66%   -2.08%     
==========================================
  Files         288      283       -5     
  Lines       44088    67057   +22969     
==========================================
+ Hits        28542    42020   +13478     
- Misses      15546    25037    +9491

Flag	Coverage Δ
CI-SqlClient	`?`
PR-SqlClient-Project	`62.66% <100.00%> (?)`

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

SSPI is an alternative to token-based authentication, not a complement to it. Previously the SspiContextProvider setter silently coexisted with AccessToken/AccessTokenCallback, leaving the connection in an ambiguous authentication state. Both token setters now throw when a context provider is already set, and the SspiContextProvider setter throws when either token property is already set. The setters continue to pass the sibling values through when building the ConnectionPoolKey: with the new validation those values are guaranteed null when a non-null value is assigned, so it only matters on the clearing path, where the remaining authentication state must survive. Also scope the IsAccessTokenProvided remark to the call sites where the token and callback paths are genuinely equivalent. Login feature-extension negotiation must keep testing the fields individually because they select different federated authentication library types (MSAL vs SecurityToken), and the previous wording invited a cleanup that would break fedauth login. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5368f578-219b-40a6-92a9-4742b56edbe6

Copilot

Pull request overview

Copilot reviewed 7 out of 8 changed files in this pull request and generated no new comments.

Files not reviewed (1)

src/Microsoft.Data.SqlClient/src/Resources/Strings.Designer.cs: Generated file

Copilot

Pull request overview

Copilot reviewed 7 out of 8 changed files in this pull request and generated 1 comment.

Files not reviewed (1)

src/Microsoft.Data.SqlClient/src/Resources/Strings.Designer.cs: Generated file

mdaigle

Requesting changes for the clone bypass, the Credential setter pool-key divergence, and missing TNIR coverage through the connection open paths.

mdaigle · 2026-08-14T17:30:22Z

+                if (value != null)
+                {
+                    // SSPI is an alternative to token-based authentication, so the two are mutually exclusive.
+                    CheckAndThrowOnInvalidCombinationOfConnectionOptionAndSspiContextProvider();


Could we copy _sspiContextProvider in the copy constructor and add a clone regression test? ICloneable.Clone() copies _accessToken and _accessTokenCallback, but not _sspiContextProvider, while CopyFrom retains the source PoolGroup. I verified that the clone reports SspiContextProvider == null while its pool key still carries the provider, and assigning AccessToken to the clone succeeds instead of throwing. This bypasses the new mutual-exclusivity validation and can authenticate with state that the public properties do not report.

Good catch, and the bypass you describe is real. Fixed in bd56892.

The copy constructor now copies _sspiContextProvider alongside _accessToken / _accessTokenCallback. Since CopyFrom retains the source PoolGroup (and therefore its ConnectionPoolKey), not copying the field left the clone reporting SspiContextProvider == null while its pool key still carried the provider, and let the caller set AccessToken without tripping the new validation.

CloneCopiesSspiContextProvider locks all three of those in: the property, the pool key, and the throw on clone.AccessToken. I verified it fails when the SqlConnection.cs fix is reverse-applied.

mdaigle · 2026-08-14T17:30:22Z

+        //  token-based authentication, so a context provider cannot be combined with AccessToken or
+        //  AccessTokenCallback. If there is any conflict, it throws InvalidOperationException.
+        //  This is to be used by the setter of the SspiContextProvider property.
+        private void CheckAndThrowOnInvalidCombinationOfConnectionOptionAndSspiContextProvider()


Could we make the Credential setter preserve or validate SspiContextProvider? It still rebuilds the pool key with sspiContextProvider: null. I verified that after setting a provider and then Credential, the public property still reports the provider while the pool key has dropped it. This leaves the same property/pool-key divergence this change fixes in the other setters.

Agreed — that was the last setter still hard-coding a sibling to null. Fixed in bd56892ac: the Credential setter now passes sspiContextProvider: _sspiContextProvider.

I went with preserve rather than validate. The two are not conceptually exclusive the way SSPI and token auth are, and adding a throw here would be a behaviour change for anyone who sets both, which this PR does not need to take on. Preserving simply removes the divergence.

CredentialSetterPreservesSspiContextProviderInPoolKey covers it, and I verified it fails without the fix.

mdaigle · 2026-08-14T17:30:22Z

+        [InlineData("my.test.server", true, true, false)]
+        [InlineData("test.database.windows.net", true, true, false)]
+        [InlineData("test.database.windows.net", false, true, false)]
+        public void TestShouldDisableTnirWithCallerSuppliedToken(


Could we add regression coverage through both Open and OpenAsync with AccessTokenCallback? This theory supplies isAccessTokenProvided as a literal, so it does not exercise IsAccessTokenProvided or LoginNoFailover. Reverting the property to _accessTokenInBytes != null leaves these tests green. Please also cover an explicit TransparentNetworkIPResolution=false; the current explicit-keyword rows only test true.

You're right on both counts, and the "reverting the property leaves these tests green" check is the useful bar. Addressed in bd56892.

Explicit TransparentNetworkIPResolution=false — the parameter is now bool? tnirInConnString (null = keyword absent) instead of a tnirExplicitlySpecified flag that always wrote true, and there are four new rows covering explicit false across both endpoint kinds and both token states.

Coverage through Open / OpenAsync — new theory AccessTokenCallbackHonorsPreLoginFedAuthRequired, run for both sync and async open. It points a real SqlConnection with AccessTokenCallback at a TdsServer started with FedAuthRequiredPreLoginOption = FedAuthRequired. The client must honour that pre-login response and echo it in the Login7 fedauth feature extension; GenericTdsServer.CheckFederatedAuthenticationOption errors out on a mismatched echo. That closes the loop through TdsParser.ConsumePreLoginHandshake → IsAccessTokenProvided. I confirmed the test goes red when IsAccessTokenProvided is reverted to _accessTokenInBytes != null: 2 failed, 0 passed.

LoginNoFailover wiring — this needed a seam, and I want to flag it since it touches production code. TNIR has no externally observable effect against a loopback simulated server, so I added SqlConnectionInternal.TnirDisabledDuringLogin, an internal bool? set from the disableTnir local inside LoginNoFailover, guarded by #if NETFRAMEWORK. The netfx arm of the same theory asserts it is true with a callback and false on a token-less baseline, which pins down that IsAccessTokenProvided is the value actually fed to ShouldDisableTnir during a real open. Precedent is IsEnhancedRoutingSupportEnabled, asserted the same way in FeatureExtensionNegotiationTests.

One caveat worth stating plainly: I'm on macOS, so I could only run the net8.0 leg locally. The netfx arm compiles under the same theory but its assertions will first execute in CI. If you'd rather not carry a test-only member in SqlConnectionInternal, the alternative is to drop that arm and accept that the LoginNoFailover wiring stays uncovered — happy to go that way if you prefer.

A note on what I could not cover: I also tried asserting the certificate-validation site (IsAccessTokenProvided && !trustServerCert in ConsumePreLoginHandshake) end-to-end, but the simulated server defaults to Encryption = NotSupported and ships no EncryptionCertificate, so TLS never completes against it and the test failed for an unrelated reason. I removed it rather than leave a test that passes for the wrong reason. That site remains covered only indirectly, through the shared property.

…tion through open - Copy _sspiContextProvider in the SqlConnection copy constructor. Clone retains the source PoolGroup, so a clone previously reported no provider while its pool key still carried one, and would accept an AccessToken that the new mutual-exclusivity validation should have rejected. - Preserve _sspiContextProvider in the Credential setter's pool key rebuild, removing the last property/pool-key divergence. - Add an end-to-end regression test that opens with AccessTokenCallback against a simulated server signalling FEDAUTHREQUIRED, through both Open and OpenAsync. The server rejects a mismatched Login7 echo, so the test fails if IsAccessTokenProvided stops accounting for the callback. - Record the TNIR decision LoginNoFailover actually applied so the .NET Framework test can assert the wiring, not just the pure ShouldDisableTnir helper. - Extend the ShouldDisableTnir theory to cover an explicit TransparentNetworkIPResolution=false. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 7 out of 8 changed files in this pull request and generated no new comments.

Files not reviewed (1)

src/Microsoft.Data.SqlClient/src/Resources/Strings.Designer.cs: Generated file

priyankatiwari08 · 2026-08-18T14:05:27Z

  <data name="ADP_InvalidMixedUsageOfAccessTokenCallbackAndIntegratedSecurity" xml:space="preserve">
    <value>Cannot set the AccessTokenCallback property if the 'Integrated Security' connection string keyword has been set to 'true' or 'SSPI'.</value>
  </data>
+  <data name="ADP_InvalidMixedUsageOfAccessTokenAndSspiContextProvider" xml:space="preserve">


These two new strings were only added to the neutral Strings.resx, not to the 13 localized Strings.*.resx files. The existing siblings (ADP_InvalidMixedUsageOfAccessTokenAndTokenCallback, ADP_InvalidMixedUsageOfAccessTokenCallbackAndIntegratedSecurity) are present in all of them, so the convention here is to add new entries everywhere in the same change.

Entry counts make the gap easy to see: Strings.resx is now at 706 <data> entries while Strings.de.resx and Strings.ja.resx are at 704. The delta is exactly these two, and they were in sync before this PR. Net effect is that both new exception messages fall back to English on every non-English install.

Could we add the two entries to the localized resx files as well?

priyankatiwari08 · 2026-08-18T14:05:28Z

+        {
+            if (_accessToken != null || _accessTokenCallback != null)
+            {
+                throw ADP.InvalidMixedUsageOfSspiContextProviderAndAccessToken();


This adds a new user-visible InvalidOperationException on a public property, but nothing under doc/ is updated in this PR. The SspiContextProvider block in doc/snippets/Microsoft.Data.SqlClient/SqlConnection.xml (around line 2217) has no <exception> element at all, and the existing <exception cref="T:System.InvalidOperationException"> on AccessToken does not mention the new SSPI conflict either.

Since setting these together used to succeed silently and now throws, callers will hit this at runtime with no documented reason. Could we add the <exception> entries for SspiContextProvider, AccessToken, and AccessTokenCallback describing the mutual exclusivity?

cheenamalhotra and others added 4 commits August 7, 2026 23:09

Potential fix for pull request finding

dbc53bf

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

Potential fix for pull request finding

964a428

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

Apply suggestions from code review

9c92fda

Co-authored-by: Cheena Malhotra <13396919+cheenamalhotra@users.noreply.github.com>

cheenamalhotra requested a review from a team as a code owner August 8, 2026 06:33

Copilot AI lite review requested due to automatic review settings August 8, 2026 06:33

github-project-automation Bot added this to SqlClient Board Aug 8, 2026

github-project-automation Bot moved this to To triage in SqlClient Board Aug 8, 2026

cheenamalhotra mentioned this pull request Aug 8, 2026

Fix AccessTokenCallback to match AccessToken behavior for TNIR and connection pool keys #4518

Closed

4 tasks

Copilot stopped reviewing on behalf of cheenamalhotra due to an error August 8, 2026 06:34
Workflow completed but conclusion is not available. This may indicate rate limiting or API issues.

cheenamalhotra requested a review from dlevy-msft-sql August 8, 2026 06:34

cheenamalhotra added Hotfix 7.0.3 PRs targeting main that should be backported to release/7.0 branch for next release. Hotfix 6.1.7 PRs targeting main that should be backported to release/6.1 branch for future hotfix labels Aug 8, 2026

cheenamalhotra added this to the 7.1.0-preview3 milestone Aug 8, 2026

cheenamalhotra moved this from To triage to In review in SqlClient Board Aug 8, 2026

github-actions Bot assigned mdaigle and paulmedynski Aug 8, 2026

Copilot AI reviewed Aug 8, 2026

View reviewed changes

Copilot AI review requested due to automatic review settings August 8, 2026 06:44

Copilot started reviewing on behalf of cheenamalhotra August 8, 2026 06:45 View session

cheenamalhotra assigned priyankatiwari08 and unassigned paulmedynski Aug 8, 2026

Copilot AI reviewed Aug 8, 2026

View reviewed changes

mdaigle requested changes Aug 10, 2026

View reviewed changes

Comment thread src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/SqlConnection.cs

github-project-automation Bot moved this from In review to Waiting for customer in SqlClient Board Aug 10, 2026

priyankatiwari08 reviewed Aug 13, 2026

View reviewed changes

Comment thread ...icrosoft.Data.SqlClient/tests/UnitTests/Microsoft/Data/SqlClient/SqlConnectionOptionsTest.cs Outdated

priyankatiwari08 reviewed Aug 13, 2026

View reviewed changes

Comment thread src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/Connection/SqlConnectionInternal.cs Outdated

Copilot AI review requested due to automatic review settings August 13, 2026 19:43

Copilot started reviewing on behalf of cheenamalhotra August 13, 2026 19:43 View session

cheenamalhotra requested review from mdaigle and priyankatiwari08 August 13, 2026 19:48

Copilot AI reviewed Aug 13, 2026

View reviewed changes

cheenamalhotra requested a lite review from Copilot August 13, 2026 23:08

Copilot started reviewing on behalf of cheenamalhotra August 13, 2026 23:08 View session

Copilot AI reviewed Aug 13, 2026

View reviewed changes

Comment thread src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/SqlConnection.cs

cheenamalhotra changed the title ~~Fix AccessTokenCallback to match AccessToken behavior for TNIR and connection pool keys~~ Fix AccessTokenCallback TNIR behavior and make SspiContextProvider mutually exclusive with token auth Aug 13, 2026

mdaigle requested changes Aug 14, 2026

View reviewed changes

Copilot AI review requested due to automatic review settings August 17, 2026 20:44

Copilot started reviewing on behalf of cheenamalhotra August 17, 2026 20:44 View session

Copilot AI reviewed Aug 17, 2026

View reviewed changes

cheenamalhotra requested a review from mdaigle August 17, 2026 21:25

priyankatiwari08 reviewed Aug 18, 2026

View reviewed changes

Uh oh!

Conversation

cheenamalhotra commented Aug 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The bug

Changes

Compatibility

Checklist

Suggested release note

Notes for reviewers

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

codecov Bot commented Aug 10, 2026

Codecov Report

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

mdaigle left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

cheenamalhotra commented Aug 8, 2026 •

edited

Loading