Re: [PATCH v3] fetch: commit references fetched before backfilling tags

On Tue, Oct 20, 2026 at 06:05:22PM -0500, Justin Tobler wrote:

On 26/10/15 11:24PM, Karthik Nayak wrote:

[snip]

quoted

Fix this by committing the previous batched update and initiating a new
one for backfilling tags. Use a separate error variable for tracking the
reference updates: One, it ensures that errors from the regular ref
updates don't cause a total failure. Two, if starting the transaction
for backfilling tags fails, only those updates are not made to disk. The
initial error is now printed straight away to clear the buffer for
further errors.

Naively, I think it would be nice if it were possible supplement the
backfill fetch "haves" with the non-committed references in the pending
transaction directly. That would avoid having to commit the references
in the middle and probably also fix it for atomic fetches too, but I'm
uncertain if that would be a simple or reasonable thing to do.

Hmm, I think that's a sensible idea. We should know about the ref
updates we have already scheduled into the transaction, so in theory we
could use their new object IDs in the negotiation. If that's possible it
would definitely be a much better fix.

Committing the intermediate state here does in part fix the issue, so it
may be a good first step regardless.

Well, if the above suggestions works we'd want to revert this step here,
so we'd first have to go back a step again.

If the above is infeasible then that's fine. But if it is feasible
without too much effort I'd go for it directly.

Patrick