Harness

@forge/monorepo

---

@forge/monorepo / backend/src / Harness

Type Alias: Harness

Harness = object

Defined in: backend/src/loadtest/harness.ts:249

Properties

effects

readonly effects: EffectLedger

Defined in: backend/src/loadtest/harness.ts:250

---

queue

readonly queue: BoundedQueue

Defined in: backend/src/loadtest/harness.ts:251

---

workers

readonly workers: readonly WorkerHandle[]

Defined in: backend/src/loadtest/harness.ts:252

Methods

admit()

admit(input): Promise<void>

Defined in: backend/src/loadtest/harness.ts:254

Admit and enqueue one run. Throws QueueFull when the queue is at its bound.

Parameters

input

conversationId

ConversationId

runId

RunId

Returns

Promise<void>

---

admittedCount()

admittedCount(): number

Defined in: backend/src/loadtest/harness.ts:294

Returns

number

---

approvePending()

approvePending(): Promise<readonly number[]>

Defined in: backend/src/loadtest/harness.ts:268

Approve everything waiting, and re-enqueue it.

A load test that left approvals pending would report them as lost work, which is the opposite of the truth: a run waiting for a human is the platform holding state correctly, and it is the longest-lived state it has. Deciding them here is also the only way the resume path is exercised under load.

Returns how long each run waited, so approval wait time is measured rather than assumed.

Returns

Promise<readonly number[]>

---

sample()

sample(): ResourceSample

Defined in: backend/src/loadtest/harness.ts:295

Returns

ResourceSample

---

settle()

settle(input): Promise<{ approvalWaitsMs: readonly number[]; completed: number; failed: number; stuck: number; stuckByStatus?: Readonly<Record<string, number>>; }>

Defined in: backend/src/loadtest/harness.ts:280

Wait until nothing with this id prefix is still in flight, then report what happened.

Necessary because "the queue is empty" is not "the work is done": the queue empties when the last job reaches a worker. Without settling, a step's slowest runs are still executing when it is measured, and they count as failures — my first staircase reported mode: errors at 20/s for exactly that reason, which would have sent an operator hunting a failure that was really my clock.

A run still non-terminal when the timeout expires does count as stuck. That is the honest line: waiting forever would hide a genuine hang, and not waiting at all reports one that is not there.

Parameters

input

idPrefix

string

timeoutMs

number

Returns

Promise<{ approvalWaitsMs: readonly number[]; completed: number; failed: number; stuck: number; stuckByStatus?: Readonly<Record<string, number>>; }>

---

statusCounts()

statusCounts(): Promise<Readonly<Record<string, number>>>

Defined in: backend/src/loadtest/harness.ts:258

Every run status and its count, so a paused run is never miscounted as a failure.

Returns

Promise<Readonly<Record<string, number>>>

---

stop()

stop(): Promise<void>

Defined in: backend/src/loadtest/harness.ts:296

Returns

Promise<void>

---

terminalCount()

terminalCount(): Promise<number>

Defined in: backend/src/loadtest/harness.ts:256

Runs in a terminal state, from the store — not from the harness's own bookkeeping.

Returns

Promise<number>

---

terminalLatencies()

terminalLatencies(idPrefix): Promise<readonly number[]>

Defined in: backend/src/loadtest/harness.ts:293

End-to-end latency per finished run, in ms, from the store's own timestamps.

The number that matters. Admission latency is a property of the enqueue and stays flat under any backlog; what a user experiences is admission to terminal, and only the store knows both ends.

Parameters

idPrefix

string

Returns

Promise<readonly number[]>