Delete several runs

Runs pile up: a day of CI, a long manual run, a suite tried ten times in a row. Deleting them one by one through each run’s own page is slow and easy to interrupt. The Runs list deletes them in one go — a pick, one question, and the runs go to the Bin in batches.

Nothing is removed outright. Deleted runs wait in Settings → Bin for 30 days, where an owner of the project can put them back (What you can undo).

Picking the runs

The first tick puts the list into picking mode, and from then on each row has a checkbox:

A row’s checkbox picks that one run. The pick holds runs from every page you pass, not just the page on screen.
The box in the head of the list picks every run on the loaded page; with some of them already picked it shows as half-ticked, and pressing it clears the page’s part of the pick.

Once a page is picked, a notice above the list says so — «All N runs on this page are selected.» — and, while the list’s filter holds more than the page it loaded, offers Select all N runs: a button with the whole number the filter holds. It picks the runs the filter matches, loaded or not — the page gathers their ids in requests of 200 and marks every one, which takes a moment on a long list.

Escape, or Clear in the bar at the bottom, gives the pick up. So does the pick itself once the runs are gone.

The question

Delete in the bar opens a dialog that says, in plural, what a single run’s dialog says:

Goes — the runs, their results, and everything they put in the review queue.
Stays — your test cases, including the ones approved out of these runs. A case outlives the run that exercised it.
The window, in the attention tone: an owner of the project can put it back for 30 days from Settings → Bin; after that it is gone for good.

Yes, delete sends it; Cancel or Escape closes it and nothing moves. There is no name to type — the runs come back from the Bin.

What happens then

The bar becomes a card that says Deleting… with a progress line — «N moved to the Bin, M left» — and a Stop button. The ids go in calls of 200, one after another, and Stop is read between them: the call in flight finishes and no next one is sent. Each call commits on its own, so a failure in the middle never un-moves what already went.

When the list settles, a Notice says what happened:

All of it — «N runs moved to the Bin», with Open the Bin to look at them or bring one back.
Some of it — «Moved N runs to the Bin» and, separately, what stayed and why:
- they are still running — a run under way is left alone, so the results it has yet to report still have a run to report to;
- was not found — already in the Bin or gone — an id the caller cannot see answers the same way, so the answer never confirms that something is sitting there;
- a count with nothing else behind it — the run stayed, and the list says so.
Stopped — how far it got, with Continue to send the rest.
Throttled — the server’s own rate ceiling answered 429. The notice waits as long as the server asked and offers Continue; nothing is lost.
Could not finish — how far it got, with Try again.
The role went away — «Nothing was deleted — you cannot delete runs in this project any more», or, if calls before it had already committed, «Moved N runs to the Bin, then you could no longer delete runs here».

Through the API

Everything the dialog does is one route:

POST /v1/runs/bulk-delete

{ "ids": ["run_1", "run_2", "run_3"] }

The answer names each run’s fate:

{
  "deleted": ["run_1", "run_2"],
  "skipped": [{ "id": "run_3", "reason": "running" }]
}

reason is running — the run still takes results — or not_found, which covers both an id this caller cannot see and one already in the Bin; the two are never told apart.
Up to 200 ids per call, the same ceiling the Bin’s own batches use. A body outside it answers 400.
10 calls a minute per caller. Past that, 429.
Each deleted run goes the way DELETE /v1/runs/{id} takes it: the cascade with it, one audit entry per run, and the queue entries under the run’s own timestamp — the way a restore matches on.
A reader is refused with 403 and nothing is taken.

The single delete is still there for one run, and it is the only delete that will take a run under way — POST /v1/runs/bulk-delete skips it on purpose.