Rebuilds
The Rebuilds page (/rebuilds, sidebar → Reliability) monitors long-running projection rebuild batches — rebuilds dispatched cell-by-cell under each database's concurrency cap by the rebuild-orchestration engine. Where the Event Store Explorer's Operations tab rebuilds one shard (or every tenant of one projection) directly, this page is for the batch-shaped jobs: a projection rebuilt across every store and tenant that hosts it, with per-cell tracking, retry, and cancel.
A cell is one unit of rebuild work — a (store, projection, tenant) combination. A single-store, single-tenant service produces a one-cell batch; a database-per-tenant service fans out one cell per tenant database, throttled per database.
The list
Two tables, refreshed every few seconds. Both list every service's batches: Rebuilds is a fleet-wide page, so the header's service selector is hidden here and does not filter the list (before 1.1.0 it still did, invisibly). The Service column says whose each batch is.
- Active — batches currently running.
- Recent — completed batches, newest first.
Both share the same columns: Batch (short id), Service, Projection, Scope, Status, Progress (a percentage bar plus n / N cells), Breakdown (done · in-flight · failed · cancelled), Requested (timestamp), and Actions (Drill in). Who requested a batch is on its detail page.
Start rebuild
Actions → Start rebuild opens a modal that composes the batch (the same menu has Refresh):
| Field | Meaning |
|---|---|
| Service | The monitored service owning the projection (pre-filled with the service last chosen in the global service selector) |
| Projection | The projection to rebuild, picked from the service's registered projections |
| Store scope | Default: every store hosting the projection; or narrow to one store |
| Tenant scope | Default (each store's default tenancy) · All tenants (one cell each) · Specific tenant |
Starting the batch shows a confirmation toast and the batch appears in Active immediately.
Batch detail
Route: /rebuilds/:batchId. Shows the batch header (status, service, projection, requested-by + requested/completed timestamps, aggregate progress bar with done · failed · cancelled · total counts) above the Cells table:
| Column | Meaning |
|---|---|
| Store | The store URI this cell rebuilds against (e.g. marten://main) |
| Projection / Tenant | The cell's projection and tenant (— for default tenancy) |
| Status | queued → dispatched → completed / failed / cancelled |
| Attempt | Retry counter — failed cells can be retried without restarting the batch |
| Node | The node executing the cell |
| Last error | The most recent failure message, when a cell has failed |
| Enqueued / Finished | Per-cell timestamps |
A status dropdown filters the cell list. In the header, Retry failed (N) re-dispatches every failed cell and Cancel batch (while the batch is in progress) stops queued cells and pauses in-flight rebuilds. Per cell, Cancel appears only on a queued or dispatched cell, and a failed cell offers Retry. Refresh re-fetches on demand (the page also live-updates).
Three rebuild paths. The Operations tab's per-row Rebuild sends the direct
RebuildProjectioncommand to the service — quick, but untracked here; its bulk Rebuild Selected instead starts tracked batches that appear on this page. The Operations tab's Rebuild later… defers that same direct command until a time you pick, held in the target service's own message store and managed on the Scheduled Messages page. Rebuilds started from this page run through the orchestration engine and get batch/cell tracking, retry, and cancel. Prefer this page for anything multi-store, multi-tenant, or long enough that you'll want to watch it.