On Fri, Nov 15, 2024 at 11:55:03AM -0800, Jonathan Tan wrote: > > So this may become more real in the future. I wonder if there is a way > > to add a test to future-proof against changes to how the quarantine > > system works. The theoretical problem case is if we did quarantine > > fetches, but accidentally wrote the new promisor pack into the main > > repo instead of the quarantine, and then a fetch rejected the incoming > > pack (because of a hook, failed connectivity check, etc). Then we'd end > > up with the new promisor pack when we shouldn't, which I guess could > > move objects from that incoming pack that we rejected into the main > > repo, despite the quarantine? > > > > I can't think of a way to test that now, without the quarantine-on-fetch > > feature existing. > > Quarantine on fetch does seem like a good idea. I also can't think of > a way to test that now. Although, for the fetch case, my patch set is > not the first time that an extra packfile (that is, a packfile not in > the "packfile" section of the fetch response) could be written during > a fetch: packfile-uris and bundle-uris already exist. So I would hope > that the implementor of the fetch quarantine feature would be aware of > at least one of these extra features, and design the test to check that > absolutely no packfiles are written if the fetch is rejected. (So I > don't think the future needs to be "proofed" so much.) Good point. I think we have to just leave it until that hypothetical future and hope that person is careful. :) -Peff
