Re: [PATCH v4 3/3] refs/reftable: reload locked stack when preparing transaction

From: Jeff King <peff@peff.net>
Date: Sep 27, 2024, 04:07 UTC
Message-ID: <20240927040752.GA567671@coredump.intra.peff.net>
In-Reply-To: <9ce2d18dff2a655365b609dd86ea484a489c717a.1727155858.git.ps@pks.im>

On Tue, Sep 24, 2024 at 07:33:08AM +0200, Patrick Steinhardt wrote:

Show 9 quoted lines

> +test_expect_success 'ref transaction: many concurrent writers' '
> +	test_when_finished "rm -rf repo" &&
> +	git init repo &&
> +	(
> +		cd repo &&
> +		# Set a high timeout such that a busy CI machine will not abort
> +		# early. 10 seconds should hopefully be ample of time to make
> +		# this non-flaky.
> +		git config set reftable.lockTimeout 10000 &&

I saw this test racily fail in the Windows CI build. The failure is as you might imagine, a few of the background update-ref invocations failed:

  fatal: update_ref failed for ref 'refs/heads/branch-21': reftable: transaction failure: I/O error

but of course we don't notice because they're backgrounded. And then the expected output is missing the branch-21 entry (and in my case, branch-64 suffered a similar fate).

At first I thought we probably needed to bump the timeout (and EIO was just our way of passing that up the stack). But looking at the timestamps in the Actions log, the whole loop took less than 10ms to run.

So could this be indicative of a real contention issue specific to Windows? I'm wondering if something like the old "you can't delete a file somebody else has open" restriction is biting us somehow.

-Peff