431 for TAKETHIS

[Don Lewis]

On Sep 17,  5:07am, Russ Allbery wrote:
} Subject: Re: 431 for TAKETHIS
} Fabien Tassin <fta at oleane.net> writes:
} 
} > It's not the goal of TAKETHIS to deal with retries. If you really want a
} > try-again-later the best way to do it is to use CHECK or IHAVE methods.
} 
} This is largely due to the problem that "try again later" was designed to
} handle.  If you have multiple peers offering you articles at the same time
} with CHECK, you may get an article offered from both peers at once.  If
} you just accept from one peer and refuse from the other, and the first
} peer never sends you the article, you may never get the article at all.
} So you send "go ahead" to one peer and send a deferral to the other.
} 
} If you've just received the entire article with TAKETHIS, there's no
} reason to do that; just accept and store the article that you just got and
} reject/refuse additional copies.

What if feed-A is running in no-CHECK mode because everything it has
been sending has been accepted the following sequence of NNTP commands
happens?
	feed-B sends "CHECK <message-ID-X>"
	response "238 <message-ID-X>"
	feed-A sends "TAKETHIS <message-ID-X>"

Judging by the comment in innfeed
          case 431:             /* try again later (also for TAKETHIS) */
I think that this is supposed to work.