e2e::directories::dep_on_current_directory spontaneous failure

[GrigorenkoPV]

Got this spontaneous failure, cannot reproduce:

---- e2e::directories::dep_on_current_directory stdout ----

thread 'e2e::directories::dep_on_current_directory' panicked at tests/e2e/directories.rs:21:5:
assertion `left == right` failed
  left: [98, 117, 105, 108, 100, 46, 110, 105, 110, 106, 97, 10, 102, 111, 111, 10, 111, 117, 116, 10]
 right: [98, 117, 105, 108, 100, 46, 110, 105, 110, 106, 97, 10, 102, 111, 111, 10, 102, 111, 111, 50, 10, 111, 117, 116, 10]
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The bytes are, correspondingly,

b"build.ninja\nfoo\nout\n"

and

b"build.ninja\nfoo\nfoo2\nout\n"

The code in question:

n2/tests/e2e/directories.rs

Lines 3 to 21 in bea43cd

	#[cfg(unix)]
	#[test]
	fn dep_on_current_directory() -> anyhow::Result<()> {
	let space = TestSpace::new()?;
	space.write(
	"build.ninja",
	"
	rule list_files
	command = ls $in > $out
	build out: list_files .
	",
	)?;
	space.write("foo", "")?;
	space.run_expect(&mut n2_command(vec!["out"]))?;
	assert_eq!(space.read("out")?, b"build.ninja\nfoo\nout\n");
	space.write("foo2", "")?;
	space.run_expect(&mut n2_command(vec!["out"]))?;
	assert_eq!(space.read("out")?, b"build.ninja\nfoo\nfoo2\nout\n");

Maybe a race condition between tests or a buffer did not get flushed?

[evmar]

That does look like a race, hmm. The test runner runs the e2e tests in parallel threads, but they each spawn a separate n2 process so there should be no buffering-related issues.

But the threads do each create their own temp dir. Those appear to use a thread-local random number generator... is it possible each thread has the same seed? I would expect more races in that case.

[evmar]

Oh wait, looking at the test, more likely it just didn't notice the directory changed. I will fix it.

[evmar]

I am sorta not sure what is going on here, because if the test usually passes that means we do see directory modifications.

It looks like stat has high resolution on Linux:
https://github.com/rust-lang/rust/blob/3736b85779d1db4c215b910004d7efcd7aff8408/library/std/src/sys/pal/unix/fs.rs#L488

[GrigorenkoPV]

but they each spawn a separate n2 process so there should be no buffering-related issues.

I mean flushing the file contents to disk after TestSpace::write, but it seems to be using std::fs::write under the hood, so probably that's not the case.