Member Junction
    Preparing search index...

    Fire-and-forget save orchestration for agent-run steps — a thin, typed façade over the shared BaseEntitySaveQueue (@memberjunction/core). Keeps step writes OFF the hot loop so a run that creates many steps (e.g. a goal-driven Computer Use loop with one prompt step per iteration) never pays N synchronous DB round-trips on its critical path, and inherits the queue's race-proofing:

    • Insert fires a step's "started" INSERT without awaiting; the step instance is the serialization key, so a later QueueUpdate chains after it (an UPDATE never races its INSERT).
    • QueueUpdate chains a force-persisted UPDATE (IgnoreDirtyState) after the step's INSERT. Its applyMutation runs INSIDE the post-INSERT task — after finalizeSave's init() + SetMany reload — so it can't be reverted (the "step stuck at Running / null TargetLogID" bug is structurally impossible). Mutating the shared entity before the INSERT resolves is the race this prevents.
    • Flush awaits every queued save, drains, and reports failure counts. Call it at run/goal finalize.

    Failures are logged, never thrown — persistence is observability and must not break the run.

    Index

    Constructors

    Methods

    Constructors

    Methods

    • Fires a step's "started" INSERT without awaiting (the caller continues immediately). The step's PK must already be client-generated (NewRecord) so its id is valid before the INSERT lands.

      Parameters

      • step: MJAIAgentRunStepEntity
      • OptionalparentStep: MJAIAgentRunStepEntity

        When provided, the INSERT is chained after the parent step's pending INSERT to satisfy the self-referencing FK_AIAgentRunStep_ParentID constraint. Without this, a child step whose fire-and-forget INSERT races the parent's INSERT can hit an FK violation.

      Returns void

    • Queues a fire-and-forget force-persisted UPDATE chained after the step's INSERT (and any prior UPDATE). Pass applyMutation for any field change made after the INSERT was fired — it runs INSIDE the post-INSERT task, so it can't be reverted by the INSERT's reload. Omitting it stays valid when the fields are already set AND cannot race an in-flight INSERT.

      Parameters

      Returns void