socket:recv/3 inconsistent behavior on Linux (OTP 26) and on OTP27.1.3 with UDP and timeout

[pguyot]

Describe the bug
On Linux, using docker containers, I can see an inconsistent behavior between OTP25, OTP26 and OTP27 and I couldn't find an explanation in OTP27.0 release notes. On macOS, the behavior is inconsistent with OTP27.1.3, which I didn't try on Linux. It may be related to OTP-19328.

socket:recv/3 (not socket:recvfrom/3) with an UDP IPv4 socket, a Length greater than available data and a positive timeout will return {ok, Data} on OTP 25 and OTP 27.0 and OTP 27.1 and {error, {timeout, Data}} on OTP 26. On macOS, OTP 25, OTP 26.2.5.5 and OTP 27.1.2 return {ok, Data}, but OTP 27.1.3 returns {error, {timeout, Data}}.

To Reproduce

podman run -it docker.io/erlang:26

then:

Addr = #{family => inet, addr => {127, 0, 0, 1}, port => 12345},
{ok, Socket1} = socket:open(inet, dgram, udp),
ok = socket:setopt(Socket1, {socket, reuseaddr}, true),
ok = socket:bind(Socket1, Addr),
{ok, Socket2} = socket:open(inet, dgram, udp),
spawn(fun() -> timer:sleep(500), ok = socket:sendto(Socket2, <<"Hello">>, Addr) end),
socket:recv(Socket1, 10, 5000).

Affected versions
OTP26 (tested with 26.0, 26.1 and 26.2.5.2).
OTP27.1.3 (tested on macOS x86 and ARM)

[bmk]

Hi,

Since this is a dgram socket and you ask to read, using recv, more data than is actually in the buffers,
the correct result in this case is {error, {timeout, Data}}.

The discrepancy between versions is unfortunate, but could be because not all fixes are back ported.

But I am not entirely sure how socket:recv should function for an unconnected DGRAM socket.

I will discuss what to do about old(er) versions (with a colleague) and report back.

[bmk]

After digging around, turns out you are correct about OTP-19328.
To solve an issue with the socket nif I/O backend on Windows,
I tweaked socket.erl and instead caused this issue for DGRAM sockets (on Unix)...