9.35.2

One fix, PostgreSQL only: #634.

📄 Upgrading to 9.35.2

SchemaUtils.DropSchema reported success when every retry failed

It retried the drop up to three times and, on the third failure, returned as though it had succeeded. One condition served two opposite outcomes:

if (success || ++reconnectionCount == maxReconnectionCount)
    return;

so the throw below the loop was unreachable, and the loop's own reconnectionCount < maxReconnectionCount could never be false either.

dropSchema reports failure for exactly one condition — 57P01 admin_shutdown — and rethrows everything else. So the only way to exhaust the attempts is a server still down after the backoff, which is precisely the case the caller needs to hear about. It heard nothing, and carried on as though the schema were gone.

An exhausted retry now throws, which is what the unreachable line always intended:

System.InvalidOperationException: Unable to drop schema: my_schema

Is this a behaviour change for you?

Only if a drop was already failing silently.

• A drop that succeeds on any of the three attempts behaves exactly as before.
• An exception that is not admin_shutdown still propagates unretried and unwrapped.
• A drop that exhausted all three attempts used to return normally and now throws. If you have a try/catch around this call that never fired, it may start firing — and what it is telling you is that the drop was not happening.

No signature changed: the public two-argument method drops its own async keyword and delegates to a new internal overload taking the single attempt as a delegate, which is source- and binary-compatible. That overload is what makes the exhausted path testable without a PostgreSQL server that stays down across three tries — the reason the defect went uncovered in the first place.