need consistent rules for retrying ftp transport operations

[Vincent Ladeuil]

The ftp transport internally handles temporary errors inconsistently.

Sometimes we reconnect, sometimes we raise an exception.

Care should be taken to analyze the implications for write operations (read operations are safe to retry).

Overall even some read operations are never retried.

[Martin Pool (mbp)]

What should be done? An audit of the ftp transport code? Or some structural change?

It seems like we ought to be able to describe some operations as retryable regardless of the particular protocol.

[Vincent Ladeuil (vila)]

Several things should/could be done in several steps:
- audit the ftp code for read operations and make them coherent ('get' reconnect on transient errors, 'has' don't for example)
- write a test ftp server that can simulate transient errors at any point (making it reusable for other protocols for an added bonus)
- audit code for write operations (this may have deeper implications than read operations and may be done in a second step)
- verify that ftp and sftp implementations are at the same level error handling wise (the ftp implementation has the notion of number_of_reties that the sftp implementation lacks)
- from the above verify that other protocols are coherent with that error handling

Due to the differences between the protocols it may not be possible to handle all operations with the same tolerance regarding transient errors but at least the above steps mentioned above should give us a better overall view.

[Vincent Ladeuil (vila)]

I'm not going to work on this bug in the foreseeable future, but feel free to ping me if you need guidance or even ideas.