Release capacity validation - 2026-07-11

Scope

The documented single-node release profile was executed on the Windows development client against a new isolated SQLite database. The harness used the production migrations, CI queue service, concurrent claim path, retained-log storage, and authenticated HTTP SSE handler. It did not connect to the running development hub.

Defect found and closed

The first exact-profile run exposed SQLITE_BUSY when five workers claimed queued builds simultaneously. ReaperCI now serializes only the short SQLite read-and-update claim transaction. Build execution remains concurrent. A scaled five-claim regression profile runs in the normal Go test suite.

Hosted Linux CI then reproduced the same primary SQLite result code while a separate commit-status service held the writer slot. Queue claims now also use a bounded, context-aware retry for SQLITE_BUSY across service boundaries. The focused claim and provider-lifecycle regressions each passed 20 consecutive runs before delivery.

Passing exact profile

Command:

go run ./cmd/reaperci-loadtest

Result:

{
  "repositories": 100,
  "servers": 30,
  "queuedBuilds": 45,
  "runningBuilds": 5,
  "buildLogBytes": 104857600,
  "simultaneousEventClients": 100,
  "minimumEventsSeenPerClient": 1656,
  "databaseBytes": 106250240,
  "seedDuration": "3.9677ms",
  "queueDuration": "129.4112ms",
  "claimDuration": "13.4572ms",
  "logDuration": "6.628042s",
  "totalDuration": "7.1264943s"
}

The 45 queued plus 5 running builds account for all 50 requested builds. Every one of the 100 authenticated SSE clients observed the ready event, all 50 queue events, 5 running events, and 1,600 retained-log events.

Boundary

This closes the repository's reproducible state/event capacity gate. Linux amd64/arm64 runtime smoke, cross-tenant managed isolation, live disk-full behavior, and separate-host restore drills remain distinct release evidence.