Skip to content

testserver: Fix race with internal socket path being ready to serve

We are still observing frequent test failures in the FetchInternalRemote test suite where gitaly-hooks fails due to an unknown-to-us error in TestFetchInternalRemote_successful():

=== CONT  TestFetchInternalRemote_successful
    fetch_internal_remote_test.go:195:
                Error Trace:        fetch_internal_remote_test.go:195
                Error:              Received unexpected error:
                                fetch: exit status 128, stderr: "error executing git hook\nfatal: ref updates aborted by hook\n"
                Test:               TestFetchInternalRemote_successful
--- FAIL: TestFetchInternalRemote_successful (7.32s)

So it's failing to execute gitaly-hooks. In this specific test, the hook service wouldn't really do anything that can fail except for calling out to the hook manager, which in turn would call the transaction manager stub. It's only based on gut feeling, but it doesn't feel plausible that the hook fails due to a random flake in this code path.

What's more likely to be the root cause is that the hook cannot reach out to the internal socket path given that we do not wait for it to become healthy. This is something we have frequently observed for the external listener, too, so it wouldn't be surprising at all.

Let's plug this hole by waiting for the internal server to become healthy.

Closes #3840 (closed)

Edited by Patrick Steinhardt

Merge request reports