The check for DBDirectClient tassert here implicitly relied on the fact that errorMayBeRetried must be false if we are in a dbDirectClient. This is because both handleStaleError and awaitShardingIntializationIfNeeded have early escapes for dbDirectClient. However, the new check doesn't do the same thing, thus allowing a dbDirectClient to call canRetryCommand where previously this was impossible. $out includes an unusual DDL path which calls internalRenameIfOptionsAndIndexesMatch which runs shardsvrRenameCollection in a dbDirectClient thus allowing us to trigger this newly added assertion while in a dbDirectClient.

If we are okay with $out having transient failures during FCV change, a fix could be as simple as modifying that check so the user receives a better error message in that case. However, fixing the underlying issue will be more difficult.