Skip to content

Stop changesets from being published while applying new spec

Warren Gifford requested to merge tb/cancel-on-apply into main

Created by: mrnugget

This is stacked on top of #13591 and is the next bit needed for #12827 (closed).

This implements the behavior described in this comment:

  • ApplyCampaign first loads the spec/campaign from the database and checks whether applying a new spec is possible
  • It then cancels all currently enqueued/erorred-but-retryable changesets so they're not published in the background.
  • The cancel blocks if there are changesets being processed.

The reason why we wait for the changesets to finish processing is that we have consistent data when we later in ApplyCampaign need to, for example, decide whether to close or simply delete a changeset. That depends on the external state of the changeset and we might make a wrong decision if we didn't finish for the changeset to finish processing.

@efritz I didn't see a way to make the "cancel all enqueued/retryable/processing changesets" query work with skip locked ... returning ID. If I were to call that in a loop, since I skip the locked ones I wouldn't know when I should exit the loop, since I don't cancel all changesets.

Merge request reports