Is it safe to rely on SqlConnection retry logic while using SqlCommand?

I was using Microsoft.Practice.TransientFaultHandling block for retry logic. Now I switched my application to .Net 4.8 and use the new build in retry logic for SqlConnection.I was wondering if I need a special retry logic for my SqlCommand (I used Polly before) or if this is also build in. There is no possibility to log a retry when relying on the build in functions which makes it really hard to test.

Microsoft states here :

"There is a subtlety. If a transient error occurs while your query is being executed, your SqlConnection object doesn't retry the connect operation. It certainly doesn't retry your query. However, SqlConnection very quickly checks the connection before sending your query for execution. If the quick check detects a connection problem, SqlConnection retries the connect operation. If the retry succeeds, your query is sent for execution."

I tested this by just disconnecting and reconnecting the internet within the retry time range and my command got executed after a while. So it seems to work for this simple scenario. But is it really safe to rely on this or do I still have to implement a retry logic for my SqlCommand?

Here is my code:

SqlConnectionStringBuilder builder = new SqlConnectionStringBuilder(ConnectionString); builder.ConnectRetryCount = 5;builder.ConnectRetryInterval = 3;MyDataSet m_myDataSet = new MyDataSet();using (SqlConnection sqlConnection = new SqlConnection(builder.ConnectionString)) {   try    {       sqlConnection.Open();    }    catch (SqlException sqlEx)    {        // do some logging                                  return false;    }    try    {        using (SqlCommand cmd = new SqlCommand(selectCmd, sqlConnection))        {                                                       using (SqlDataAdapter da = new SqlDataAdapter(cmd))                {                    da.Fill(m_myDataSet, tableName);                }                                  }    }           }