Re: Repository corruption if objects pushed in the middle of repack

[Taylor Blau <me@ttaylorr.com>]

On Mon, Jun 13, 2022 at 05:32:21PM -0400, Konstantin Ryabitsev wrote:
> On Mon, Jun 13, 2022 at 05:24:27PM -0400, Taylor Blau wrote:
> > A much more likely explanation for what is going on has to do with the
> > `--unpack-unreachable` option you're using.
> >
> > In your example, any unreachable object written within the last day is
> > written loose, and anything else older than that is simply discarded. If
> > the following happens, in order:
> >
> >   - an unreachable object is detected, and marked for deletion
> >   - that object then becomes reachable via some ref-update
> >   - then the object becomes an ancestor of some push which depends on it
> >   - _then_ the object is deleted by repack
> >
> > ...then the repository will be missing some objects which are in its
> > reachable set, and thus corrupt. IOW, the `--unpack-unreachable` option
> > (and its successor, cruft packs) are both racy with respect to
> > ref-updates.
> >
> > Are you able to find evidence of that race in your logging? I would bet
> > that is likely what is going on here.
>
> I'm not sure that's the case, because the object that is missing is the one
> that didn't exist before the repack started. In the scenario you describe, the
> pre-existing unreachable ancestor of it would be missing, not the newly
> incoming object. Right?

Aren't we reporting that the newly pushed tree was broken _because_ it
had some links to sub-trees that no longer existed?

Thanks,
Taylor