Curious about real example raising race condition when using v3 - Githubissues

kubernetes / git-sync

A sidecar app which clones a git repo and keeps it in sync with the upstream.

Apache License 2.0

2.13k stars 406 forks source link

Curious about real example raising race condition when using v3 #880

Closed hans818Tossbank closed 4 weeks ago

hans818Tossbank commented 1 month ago

Hi, I’m using git sync components at airflow cluster in kubernetes.

We need to consider of operating git-sync components with multiple replicas because of HA.

And I found really great document for explaining about how does git-sync work.

But ... I can not come up with real example when using git sync in airflow cluster, why does v3 mechanism raise race condition and make some bugs related to back to back runs of git sync.

Could you please real example when does v3 make race condition in airflow and why is v4 secure when using git init + git fetch <remote> <refs> ?

thockin commented 4 weeks ago

The race was like this:

Running git-sync with a low --depth (e.g. --depth=1)
Git-sync resolves the branch to a SHA (e.g. AAAAA) and syncs
User pushes an update to git repo, SHA is BBBBB
Git sync wakes up and sees that the branch resolves to SHA BBBBB
User pushes an update to git repo, SHA is CCCCC
Git-sync fetches the branch, gets CCCCC
Git-sync tries to reset to BBBBB
BBBBB is not in the local repo because depth was 1

In v4, we would fetch the branch and resolve it to CCCCC in one step.

Hope that helps!