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
