Skip to content

When reconciler updates commit of changeset the diff view is outdated until the next sync

Created by: mrnugget

When the reconciler updates the commit of a changeset (after applying a new campaign spec) we simply push the commit to the codehost and do an early exit:

https://github.com/sourcegraph/sourcegraph/blob/7b4581440dcb47274f6dd671497ebf626c69f1c6/enterprise/internal/campaigns/reconciler.go#L197-L214

The problem is that this means that the new commit SHA is not saved on the changeset, which means we still use the old one that's saved in the metadata of the changeset:

https://github.com/sourcegraph/sourcegraph/blob/7b4581440dcb47274f6dd671497ebf626c69f1c6/internal/campaigns/types.go#L668-L682

There's multiple ways to do this:

  1. Easy and unoptimised: we change the return tx.UpdateChangeset into return r.syncChangeset(ctx, tx, ch), which will sync the changeset (pulling down the new headref from the codehost) and save the new data to the DB.
  2. Hacky and optimised: we change the r.gitserverClient.CreateCommitFromPatch(ctx, opts) call to not only return the revision we just updated (the branch name) but also the new commit SHA. We then save that commit SHA on the changeset by (here comes the hacky part) patching the changeset.Metadata so that HeadRefOID from above returns the new commit SHA.

Solution (1) is easy but has the drawback that it adds another full sync to the system, which could run into a rate limit, and there's a possible race condition where we push the new commit, but the updated head ref is not returned in the sync, which makes the whole costly sync-call useless.

Solution (2) is hacky because we fiddle around with internals of changeset.Metadata, but maybe we could add a field to changesets called CachedHeadRefOID that's reset on the next sync?