Skip to content

The run log lifetime is the engine process, and nothing says when an app must copy #2106

Description

@joshuadarron

The app's run archive held eleven runs, the newest three days old, while the same database was recording crew starts that afternoon. No errors anywhere.

Filed from section 4.7 of the Rocket CRM runtime findings (docRevision 252). Part of the Rocket CRM build tracked in rocketride-ai/rocketride-saas#456.

Mechanism

runs_sync copies runs out of the engine's log, and we ran it once per connection, eight seconds after connecting — which is before the session's first question. The log is per engine process. Every turn asked after that one sweep was gone by the time anything looked again. The runs that did survive came from sessions that happened to reconnect after a few turns, which is why the failure looked like flakiness rather than a rule.

getTrace's retention horizon is the documented eviction. This is the undocumented one: process lifetime, which in development is minutes. "Durable the moment a run seals" is true, and was read as "durable".

What we do today

Sweep after each turn as well — debounced, fired not awaited, because it shares the node's single-file op queue.

Ask

  1. Say a run log's lifetime as clearly as its retention horizon, in the observability docs and at the point of use.
  2. A seal-time hook — the same ask as the eviction issue (section 4.2) — removes the guesswork entirely: an app that is told when a run is complete never has to decide when to sweep.

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    docsDocumentationmodule:aiAI/ML modulespriority:highMajor feature broken or silently wrong, workaround costly, shipped regression, dated commitment

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions