Fix | Scope configurable retry logic assembly resolution to opt-in callers

[priyankatiwari08]

Summary

SqlConfigurableRetryLogicLoader subscribed a handler to AssemblyLoadContext.Default.Resolving in its constructor and never removed it.

SqlConfigurableRetryLogicManager builds that loader lazily on the default RetryLogicProvider path, so simply reading SqlCommand.RetryLogicProvider or SqlConnection.RetryLogicProvider — which any app using retry logic does — installed a permanent, process-wide assembly resolution hook.

Two consequences:

1. It applied to everything. Once installed, the handler participated in resolving every assembly the host application failed to find, even though the application had never configured a custom retry logic type. Apps saw failures (and in Stack overflow caused by SqlConfigurableRetryLogicLoader.Defaul_resolving #2214 a stack overflow) surfacing from inside SqlClient for assemblies that have nothing to do with SqlClient.
2. It probed the wrong directory. The handler resolved against Environment.CurrentDirectory. The documented contract is the application's executing directory — AppContext.BaseDirectory — so probing the working directory was already a deviation. The working directory is ambient process state that any code in the process can change and bears no relationship to where the application's binaries live, so assemblies could be resolved from an unintended location.

Only .NET is affected — the .NET Framework code path does not use AssemblyLoadContext.

Scope

This is the mitigation intended for the hotfix branches: 7.1.0, backported to 7.0 and 6.1 so the issue is resolved on all production branches. It deliberately does not change the underlying design of how retry logic assemblies are loaded.

The two larger design questions raised in review — loading configured retry logic into a dedicated AssemblyLoadContext, and replacing type-name resolution with an explicit registration API — are tracked separately in #4623 for 8.0.

Changes

#	Change
1	Probe AppContext.BaseDirectory instead of Environment.CurrentDirectory.
2	Subscribe the resolving handler only when a custom retryLogicType is configured, and only for the duration of resolving and constructing that provider.
3	Skip type resolution entirely when no retryLogicType is configured.

On (3): in AppConfigManager, retryLogicType is optional while retryMethod is IsRequired = true. So a config that selected a built-in retry method still went through the custom-type resolution path and installed the handler. It now short-circuits straight to SqlConfigurableRetryFactory.

On (2): the handler spans both LoadType and CreateInstance. LoadType only produces a Type — the configured type's constructor and retry method run inside CreateInstance, and a provider that touches its own private dependencies while being constructed needs the handler installed at that point.

Net effect: the handler is never installed unless the application explicitly configured a custom retry logic type, and it is removed again once that provider has been constructed.

Compatibility

Three behavioural changes, in decreasing order of legitimacy:

1. A provider that loads a private dependency after construction — at retry time — no longer finds it through the driver's handler. Legitimate but never reliable, since it required the dependency to be in CWD at the moment the retry fired. Mitigation: reference the dependency so it lands in deps.json, or register a resolving handler in the application.
2. A custom retry type resolvable only from the working directory no longer resolves. This aligns the implementation with the documented executing-directory contract. Mitigation: move the assembly to AppContext.BaseDirectory.
3. Unrelated application assemblies that were incidentally resolved by the process-wide hook no longer are. This has the widest reach — it did not require retryLogicType to be configured at all — but no legitimate reliance.

We intentionally do not keep the process-wide handler installed, because the driver should not alter assembly resolution for the whole application on behalf of configurable retry logic. The dedicated AssemblyLoadContext tracked in #4623 closes case 1 properly.

Tests

• New SqlConfigurableRetryLogicLoaderTest (UnitTests — needs InternalsVisibleTo, which FunctionalTests does not have). Covers: no configuration, config without retryLogicType, whitespace-only retryLogicType, and an unresolvable retryLogicType — asserting in each case that no handler declared by the loader remains attached to AssemblyLoadContext.Default.Resolving.
• New RetryLogicTypeResolution_KeepsAssemblyProbingEnabledWhileProviderIsConstructed. Plants a retry factory whose constructor asserts, from inside CreateInstance, that the handler is installed, and asserts it is gone once resolution returns — so both the add and the remove are observed, at the point in the sequence that matters.
• New AssemblyResolutionSubscription_DisposeRemovesAssemblyProbingHandler. Directly verifies that disposing the scoped subscription removes its handler.
• New Constructor_WithResolvableRetryLogicType_DoesNotLeaveAssemblyProbingEnabled. Resolves a retry factory through the probing directory and confirms via an invocation counter that it really was used, so it exercises successful resolution rather than a silent fallback — then asserts no handler remains.
• New RetryLogicProviderDoesNotLeaveAssemblyProbingEnabled (FunctionalTests). Plants a non-assembly file named <guid>.dll in AppContext.BaseDirectory and asserts Assembly.Load reports FileNotFoundException rather than BadImageFormatException. No process-wide state is modified.

The directory and handler-leak tests were confirmed to fail against the pre-fix code and pass after.

Validated on net462, net8.0, net9.0, and net10.0.

Checklist

• Tests added
• No public API changes (all affected types are internal), so no ref/ updates required
• Breaking changes assessed — no public API change; three behavioural changes documented under Compatibility
• Verified against the reported scenario in Stack overflow caused by SqlConfigurableRetryLogicLoader.Defaul_resolving #2214

Suggested release note entry

Fixed SqlConfigurableRetryLogicLoader installing a permanent, process-wide AssemblyLoadContext.Default.Resolving handler that probed the current working directory. The handler is now installed only while a configured custom retry logic type is being resolved and constructed, and probes the application base directory. (#2214)

Related

Refs #2214, #2134
Follow-up design work tracked in #4623

[Copilot]

Pull request overview

This PR fixes SqlConfigurableRetryLogicLoader’s .NET AssemblyLoadContext.Default.Resolving usage so it only applies to explicit opt-in callers (custom retry-logic type resolution) and no longer probes the process working directory.

Changes:

• Switch configurable retry-logic assembly probing from Environment.CurrentDirectory to AppContext.BaseDirectory.
• Scope AssemblyLoadContext.Default.Resolving subscription to the duration of the Type.GetType(...) call (subscribe + finally unsubscribe).
• Skip custom type resolution entirely when retryLogicType is not configured (use built-in factory directly).
• Add unit + functional regression tests validating the handler is not left attached and that current-directory probing is not enabled.

Reviewed changes

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

File	Description
src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/Reliability/SqlConfigurableRetryLogicLoader.cs	Scopes the resolving handler to opt-in type resolution and switches probing to AppContext.BaseDirectory.
src/Microsoft.Data.SqlClient/tests/UnitTests/Microsoft/Data/SqlClient/SqlConfigurableRetryLogicLoaderTest.cs	New unit tests validating no SqlConfigurableRetryLogicLoader resolving delegates remain attached.
src/Microsoft.Data.SqlClient/tests/FunctionalTests/SqlConfigurableRetryLogicTest.cs	Adds functional regression test ensuring retry-logic initialization does not enable current-directory assembly probing.

---

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

[benrr101]

Since it's still a draft, leaving a comment

[Copilot]

Pull request overview

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

[paulmedynski]

These changes don't remove the attack surface - they narrow it. Can we do better?

Also, we're missing tests that prove we add and then remove Default_Resolving from the default ALC under all of the code paths, and that we don't add it at all in some cases.

[codecov]

Codecov Report

❌ Patch coverage is 95.65217% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 63.76%. Comparing base (bd36b43) to head (6476d99).
⚠️ Report is 19 commits behind head on main.

Files with missing lines	Patch %	Lines
...ent/Reliability/SqlConfigurableRetryLogicLoader.cs	95.65%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4547      +/-   ##
==========================================
- Coverage   64.75%   63.76%   -1.00%     
==========================================
  Files         288      284       -4     
  Lines       44418    67920   +23502     
==========================================
+ Hits        28763    43307   +14544     
- Misses      15655    24613    +8958     

Flag	Coverage Δ
CI-SqlClient	?
PR-SqlClient-Project	63.76% <95.65%> (?)

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.

[Copilot]

Pull request overview

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

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

src/Microsoft.Data.SqlClient/tests/FunctionalTests/SqlConfigurableRetryLogicTest.cs:127

• Cleanup is described as best-effort, but File.Delete can throw exceptions other than IOException (e.g., UnauthorizedAccessException). To keep this regression test from failing due to cleanup issues in restrictive environments, catch a broader exception (or explicitly include UnauthorizedAccessException) in the cleanup block.

                catch (IOException)