test 596 flakiness

[icing]

I did this

I ran:

make -j20 && (cd tests && make -j20 && ./runtests.pl --repeat=100 596)

which eventually fails the test with:

 596: protocol FAILED:
--- log/check-expected	2024-01-31 10:29:38
+++ log/check-generated	2024-01-31 10:29:38
@@ -5,4 +5,3 @@
 TYPE I[CR][LF]
 SIZE 596[CR][LF]
 RETR 596[CR][LF]
-QUIT[CR][LF]

 - abort tests

what I see then in the log file is:

0000: 150 Binary data connection for 596 () (4 bytes).
10:29:38.694577 == Info: Maxdownload = -1
10:29:38.694686 == Info: Getting file with size: 4
10:29:38.694807 == Info: Preparing for accepting server on data port
10:29:38.694969 == Info: Checking for server connect
10:29:38.695129 == Info: Ctrl conn has data while waiting for data conn
10:29:38.695299 <= Recv header, 28 bytes (0x1c)
0000: 226 File transfer complete
10:29:38.695516 == Info: [FTP] recv 0 bytes, ftpcode=226
10:29:38.695667 == Info: ftp AllowServerConnect() -> 8
...

which is the error code CURLE_WEIRD_SERVER_REPLY on seeing the 226 response on the control connection before curl has retrieved the file. See ftp.c:421.

What I believe happens here is that the POLL event on the control socket arrives sometimes before the event on the data socket. The server probably has sent the 4 data bytes of the "file" and directly wrote the 226 response on the control. Since the OS makes no guarantee in what order socket event arrive at the peer, this seems to point to a bug in the curl code.

I expected the following

The test to work reliably.

curl/libcurl version

8.7.0-DEV

operating system

macOS

[icing]

After looking at the code, one way to fix this is to do a "peek" at the response in ftp.c:415 instead of consuming the response. If the "peek" finds a 226, the accepting should continue and keep the 226 around for when it succeeds.