WaitHandle replacement activation failure loses the original pooled connection

[mdaigle]

Describe the bug

When WaitHandleDbConnectionPool.ReplaceConnection creates a replacement successfully but the replacement throws during activation, CreateObject has already removed the original connection from _objectList and added the replacement. PrepareConnection then returns the failed replacement to the idle pool.

The original connection remains alive and checked out but is no longer tracked by _objectList, while the failed replacement remains pooled instead of being disposed. Pool ownership and metrics no longer describe the physical connections accurately, and the original connection cannot be reclaimed through ReclaimEmancipatedObjects.

If you are seeing an exception, include the full exceptions details (message and stack trace).

Exception message: The replacement's activation exception is propagated.
Stack trace: N/A

To reproduce

Use a test connection factory whose first connection activates normally and whose second connection opens successfully but throws from Activate. Acquire the first connection, then call WaitHandleDbConnectionPool.ReplaceConnection.

DbConnectionInternal original = GetConnection(pool, owner);
factory.FailReplacementActivation = true;
Assert.Throws<TestActivationException>(() =>
    pool.ReplaceConnection(owner, original, timeout));

After the exception, the failed replacement is not disposed and is counted as free, while the live original is absent from the pool's tracking list.

Expected behavior

Dispose the failed replacement, restore the original connection to the pool's tracking list, and leave the original checked out for the caller's reconnect retry. Hard, soft, pooled, free, and active connection counters should reflect exactly that state.

Further technical details

Microsoft.Data.SqlClient version: current main
.NET target: .NET 9.0 reproduction; shared pool code also targets .NET 8.0 and .NET Framework 4.6.2
SQL Server version: Not applicable; deterministic unit-test reproduction uses a fake connection factory
Operating system: macOS; issue is platform-independent

Additional context

ChannelDbConnectionPool.ReplaceConnection already preserves the original until the replacement is fully activated. The WaitHandle implementation should provide the same rollback behavior.

[github-actions]

🔍 Triage Summary

Check	Result
Issue type	Bug
Environment	All required environment details provided for investigation
Area	Area\Connection Pooling
Duplicates	None found
Regression	Not indicated (targets current main)

Analysis

This bug affects WaitHandleDbConnectionPool.ReplaceConnection: when a replacement connection is successfully created but throws during Activate, the original connection has already been removed from _objectList and replaced by the failing connection, which is then returned to the idle pool instead of being disposed. The result is a tracking inconsistency — the live original connection is orphaned (un-reclaimable via ReclaimEmancipatedObjects) while a broken connection occupies a pool slot. The reporter notes that ChannelDbConnectionPool.ReplaceConnection already handles this correctly via rollback semantics. This is a P2 data-consistency bug in the WaitHandle pool path affecting .NET Framework and .NET 8/9.

Next Steps

• Assign to Copilot coding agent to investigate WaitHandleDbConnectionPool.ReplaceConnection in src/Microsoft.Data.SqlClient/src/.
• The fix should mirror ChannelDbConnectionPool.ReplaceConnection: keep the original connection in _objectList until the replacement is fully activated; on activation failure, dispose the replacement, restore the original to _objectList, and return it as checked-out.
• Add unit tests (using a fake factory where FailReplacementActivation = true) asserting that after a failed replacement: (1) the failed replacement is disposed, (2) the original remains in the tracking list, and (3) hard/soft/free/active counters are consistent.

Note: This triage summary is auto-generated by an AI agent. The analysis and suggestions above have not been verified by a human maintainer. Please treat as preliminary guidance only.

Generated by SqlClient Issue Auto-Triage for issue #4548 · 28.2 AIC · ⌖ 8.97 AIC · ⊞ 8.6K · ◷

[cheenamalhotra]

Its a nice edge case capture!