stablyai/orca · error · Error

ORCA_REPLAY_BENCH_SECONDS must be positive, received

Error message

ORCA_REPLAY_BENCH_SECONDS must be positive, received ${SECONDS}

What it means

Thrown by the relay replay-buffer benchmark when ORCA_REPLAY_BENCH_SECONDS is not a finite positive number. The env var scales the per-second PTY chunk count into a fixture (chunksPerSecond * SECONDS), so zero/negative would build an empty fixture and non-numeric would propagate NaN into the timing loop. The default is '1'.

Solutions

1. Omit the env var entirely to use the default of '1' second of simulated output.
2. Set ORCA_REPLAY_BENCH_SECONDS to a positive integer or decimal, e.g. ORCA_REPLAY_BENCH_SECONDS=2.

Example fix

// before
ORCA_REPLAY_BENCH_SECONDS=0 node config/scripts/relay-replay-buffer-benchmark.mjs
// after
ORCA_REPLAY_BENCH_SECONDS=2 node config/scripts/relay-replay-buffer-benchmark.mjs

const raw = process.env.ORCA_REPLAY_BENCH_SECONDS ?? '1'
const seconds = Number(raw)
if (!Number.isFinite(seconds) || seconds <= 0) {
  throw new Error(`Set ORCA_REPLAY_BENCH_SECONDS to a positive number, got ${raw}`)
}

function isPositiveFinite(value) {
  return typeof value === 'number' && Number.isFinite(value) && value > 0
}

When it happens

Trigger: Running the benchmark with ORCA_REPLAY_BENCH_SECONDS set to '0', a negative number like '-2', or a non-numeric string like 'fast' or ''. The check uses Number.isFinite() so Infinity and NaN both fail.

Common situations: A developer sets the value to 0 trying to run a quick sanity check, or leaves an empty assignment (ORCA_REPLAY_BENCH_SECONDS=) in a shell command, or typos the value.

Related errors

• must be a positive integer, received
• must be a positive integer, received
• must be a positive integer, received
• must be a positive integer, received
• ORCA_ADVERTISED_URL_BENCH_ROUNDS must be even

AI-assisted analysis of stablyai/orca@1136503c6a (2026-08-12). Data as JSON: /api/errors/e36c112c0854e058. Report an issue: GitHub.

Appendix: source

Thrown at config/scripts/relay-replay-buffer-benchmark.mjs:21

//
// appendReplayBuffer did `buffered += data` then, over the cap, `buffered.slice(-CAP)`.
// Once a PTY has produced CAP bytes -- which a long-lived shell does almost immediately
// -- every subsequent chunk flattened and copied the whole 100 KB window. The append is
// called per raw node-pty emission, before batching, so it is per chunk, not per flush.
//
// The fix reuses RecentPtyOutputBuffer: keep chunks, drop from the head, and defer the
// join to read(), which only attach/adopt/revive call.
//
// Both arms are compared for an identical retained tail before timing.
//
// Run with:  node config/scripts/relay-replay-buffer-benchmark.mjs
import { readFileSync } from 'node:fs'
import { performance } from 'node:perf_hooks'

const ROUNDS = 6
const SECONDS = Number(process.env.ORCA_REPLAY_BENCH_SECONDS ?? '1')
if (!Number.isFinite(SECONDS) || SECONDS <= 0) {
  throw new Error(`ORCA_REPLAY_BENCH_SECONDS must be positive, received ${SECONDS}`)
}

// Why re-read the sources: the claim is that the relay now appends into a chunk deque
// with the relay's own cap. If either reverts, these numbers stop meaning what they say.
const HANDLER_SOURCE = readFileSync(
  new URL('../../src/relay/pty-handler.ts', import.meta.url),
  'utf8'
)
if (!/managed\.buffered\.append\(/.test(HANDLER_SOURCE)) {
  throw new Error('relay no longer appends into a chunk deque; this benchmark is stale')
}
const capMatch = HANDLER_SOURCE.match(/REPLAY_BUFFER_MAX = ([\d *]+)/)
if (!capMatch) {
  throw new Error('REPLAY_BUFFER_MAX not found; this benchmark is stale')
}
// The regex admits only digits, spaces, and `*`, so the literal is a plain product.
const REPLAY_BUFFER_MAX = capMatch[1]
  .split('*')

View on GitHub (pinned to 1136503c6a)