walkpath Channel behaviour, and a suspicious test in test/file.jl

[nlw0]

Replicating this test on a Julia console, it actually does not seem to work:

julia/test/file.jl

Lines 1387 to 1388 in 62dd14e

	@test_throws(Base._UVError("readdir($(repr(joinpath(".", "sub_dir1"))))", Base.UV_ENOENT),
	take!(chnl_error)) # throws an error because sub_dir1 do not exist

               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.7.1 (2021-12-22)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> JuliaSnail.start(10011) ; # please wait, time-to-first-plot...

julia> using Test

julia> dirwalk = mktempdir();

julia> cd(dirwalk);

julia> for i=1:2
       mkdir("sub_dir$i")
       open("file$i", "w") do f end
       mkdir(joinpath("sub_dir1", "subsub_dir$i"))
       touch(joinpath("sub_dir1", "file$i"))
       end

julia> touch(joinpath("sub_dir2", "file_dir2"));

julia> chnl_error = walkdir(".");

julia> take!(chnl_error);

julia> rm(joinpath("sub_dir1"), recursive=true);

julia> @test_throws(Base._UVError("readdir($(repr(joinpath(".", "sub_dir1"))))", Base.UV_ENOENT), take!(chnl_error)) # throws an error because sub_dir1 do not exist
Test Failed at REPL[10]:1
  Expression: take!(chnl_error)
    Expected: Base.IOError("readdir(\"./sub_dir1\"): no such file or directory (ENOENT)", -2)
  No exception thrown
ERROR: There was an error during testing

I believe asynchronous execution might make the test pass on the build machine, but it still can fail in different circumstances.

My understanding of how walkdir is working is that by the time we call the first take!, it can already eagerly execute the code until the next push!, meaning that readdir("sub_dir1") is called before rm(joinpath(.... Therefore the second take! has no errors, although another one will fail on readdir("./sub_dir1/subsub_dir2").

If execution in the build machine is somehow more "lazy", though, it may be running the code after the first push! only when the second take! is called, and by then there's time for rm to run and readdir to fail, as the test intends.

Looks like a broken test in my opinion. I stumbled on this because I was trying to make an old PR pass the tests (#33478), and I think this started to fail because my patch affected the execution timing.