Rulvar API reference / @rulvar/cli / CreateServerOptions
Interface: CreateServerOptions
Defined in: packages/cli/src/server.ts:67
Properties
| Property | Type | Description | Defined in |
|---|---|---|---|
engine | Engine | - | packages/cli/src/server.ts:68 |
maxBufferedEventsPerRun? | number | Upper bound on buffered SSE replay events per tracked run: past the bound the OLDEST buffered events are dropped in chunks (so the retained replay window stays at least seven eighths of the bound) and counted. A replay that no longer reaches back to a client's cursor carries x-rulvar-events-dropped: <count> and a leading SSE comment naming the first retained seq; the journal remains the durable record of the run itself. Defaults to DEFAULT_MAX_BUFFERED_EVENTS_PER_RUN (RV409; before v1.94.0 absent meant unbounded, and an explicit huge bound such as Number.MAX_SAFE_INTEGER restores that behavior in effect). Validated at construction: a positive safe integer, anything else is a typed ConfigError. | packages/cli/src/server.ts:121 |
maxPendingEventsPerClient? | number | Upper bound on SSE frames PENDING in one client connection's response queue, replay and live feed alike (v1.26.0 deep E2E review P1-2: the replay buffer bound does not bound what a connected consumer that stopped reading accumulates). When a connection's pending queue reaches the bound, the server unhooks the feed, appends an SSE comment naming the bound, and CLOSES that connection; queued frames stay readable, and the standard Last-Event-ID reconnect resumes strictly after the last frame the client consumed. A replay longer than the bound is likewise delivered in bounded chunks across reconnects, so pending memory per connection is O(bound), never O(events). Validated at construction: a positive safe integer. Defaults to 10000. | packages/cli/src/server.ts:136 |
maxTrackedRuns? | number | Cap on SETTLED tracked runs kept in process memory: when a run settles terminally and neither retention released it, the oldest settled tracked runs beyond the cap are released exactly like a memoryRetention verdict (durable state untouched). Live runs are never evicted and do not count toward the cap. Absent means no cap. Validated at construction: a non-negative safe integer (zero keeps no settled runs), anything else is a typed ConfigError. | packages/cli/src/server.ts:106 |
memoryRetention? | (meta) => boolean | Opt-in retention of PROCESS MEMORY, decoupled from the durable kind (v1.25.0 scale review P1-2): evaluated when a tracked run settles terminally, after retention; a true verdict releases the tracked state (args, outcome, handle, SSE buffer) while the journal and transcripts stay untouched, after which GET status/cost serve from the store exactly as for a run another process owns, and GET events answers with the documented empty stream for a run not live here. | packages/cli/src/server.ts:96 |
priceUsd? | (servedBy, usage) => number | undefined | Prices the journal fold behind GET /runs/:id/cost for runs without a settled in-process outcome (the host assembles pricing exactly as it does for the CLI); absent means those usages surface as unpriced, never a silent zero. | packages/cli/src/server.ts:77 |
retention? | (meta) => boolean | Opt-in DURABLE retention (OQ-20 executed at M8-T04): evaluated when a tracked run settles terminally; a true verdict applies engine.deleteRun (transcript cascade, then the journal) and untracks the run. This deletes the durable record; to release only process memory, use memoryRetention or maxTrackedRuns. Absent means nothing is deleted. | packages/cli/src/server.ts:86 |
workflows | WorkflowRegistry | The explicit, first-class registry. | packages/cli/src/server.ts:70 |