assistant: when an add fails, requeue it for later

See analysis in bug report for one way this could happen.

2 files changed, 26 insertions, 3 deletions

diff --git a/Assistant/Threads/Committer.hs b/Assistant/Threads/Committer.hs
index aaec25206..04f94143b 100644
--- a/Assistant/Threads/Committer.hs
+++ b/Assistant/Threads/Committer.hs
@@ -256,14 +256,14 @@ handleAdds delayadd cs = returnWhen (null incomplete) $ do
 		| otherwise = a
 
 	add :: Change -> Assistant (Maybe Change)
-	add change@(InProcessAddChange { keySource = ks }) = do
+	add change@(InProcessAddChange { keySource = ks }) =
 		alertWhile' (addFileAlert $ keyFilename ks) $
 			liftM ret $ catchMaybeIO <~> do
 				sanitycheck ks $ do
 					key <- liftAnnex $ do
 						showStart "add" $ keyFilename ks
 						Command.Add.ingest $ Just ks
-					maybe failedingest (done change $ keyFilename ks) key
+					maybe (failedingest change) (done change $ keyFilename ks) key
 	  where
 		{- Add errors tend to be transient and will be automatically
 		 - dealt with, so don't pass to the alert code. -}
@@ -306,7 +306,8 @@ handleAdds delayadd cs = returnWhen (null incomplete) $ do
 		mkpairs k = map (\c -> (inodeCacheToKey ct c, k)) <$>
 			recordedInodeCache k
 
-	failedingest = do
+	failedingest change = do
+		refill [change]
 		liftAnnex showEndFail
 		return Nothing
 
diff --git a/doc/bugs/assistant_does_not_warn_on_files_it_failed_to_add.mdwn b/doc/bugs/assistant_does_not_warn_on_files_it_failed_to_add.mdwn
index 230841e9f..6539dc9e8 100644
--- a/doc/bugs/assistant_does_not_warn_on_files_it_failed_to_add.mdwn
+++ b/doc/bugs/assistant_does_not_warn_on_files_it_failed_to_add.mdwn
@@ -22,3 +22,25 @@ OS: Arch Linux
 Please provide any additional information below.
 
 The assistant in this case is being used as nothing more than a way for me to see which files have been added (--verbose, --foreground and --debug with 'watch' outputs nothing..). No remotes or anything like that.
+
+> I have made the assistant re-queue any file that it fails to add,
+> so it will retry it later. Typically within a few seconds. [[done]]
+> 
+> I have only been able to think of one scenario in which this could
+> happen. It's pretty unusual:
+> 
+> * Something writes to a file, and closes it.
+> * Assistant sees file has no writers, and locks it down in preparation
+>   to add it.
+> * Something then re-opens the file to write to it some more.
+>   Note that it would seem to need to bypass permissions that prevent
+>   the file from being written to in order to do this. It makes a change
+>   to the file.
+> * Assistant is checksumming file, reaches end, and detects it has been
+>   tampered with and gives up.
+> 
+> I would still like more information about circumstances that
+> cause this to happen, because while a possible scenario, the 
+> above is too weird to believe anyone could run into it.
+> 
+> --[[Joey]]