Also do forward retrying in cases where no exception is thrown, but the transfer failed.

I think this used to be the case, but it was accidentially lost way back in
commit 3887432c54. Normally, transfers do not
throw exceptions, so probably forward retrying was rarely done due to that
oversight.

This also affects the new annex.retry etc configuration. If a transfer
fails, without making any progress, eg because the file is not present on
the remote or the remote is not accessible, it will now retry when
configuration calls for it. In some cases such a retry is not desirable,
for example the remote could be accessible and not have a copy of the file
that the local repo thinks it has. I see no way to distinguish such cases
from cases where a retry should really be done. So, it'll be up to the user
to configure it to work for them.

Annex/Transfer.hs

@@ -135,9 +135,14 @@ runTransfer' ignorelock t afile retrydecider transferaction = checkSecureHashes
 		void $ tryIO $ removeFile lck
 #endif
 	retry shouldretry oldinfo metervar run = tryNonAsync run >>= \case
-		Right b -> return b
+		Right v
+			| observeBool v -> return v
+			| otherwise -> checkretry
 		Left e -> do
 			warning (show e)
+			checkretry
+	  where
+		checkretry = do
 			b <- getbytescomplete metervar
 			let newinfo = oldinfo { bytesComplete = Just b }
 			ifM (shouldretry oldinfo newinfo)

CHANGELOG

@@ -6,6 +6,8 @@ git-annex (6.20180317) UNRELEASED; urgency=medium
     by not bundling libz, assuming OSX includes a suitable libz.1.dylib.
   * Added annex.retry, annex.retry-delay, and per-remote versions
     to configure transfer retries.
+  * Also do forward retrying in cases where no exception is thrown,
+    but the transfer failed.
 
  -- Joey Hess <id@joeyh.name>  Mon, 19 Mar 2018 23:13:59 -0400