Skip to content

fix(runtime): make concurrent participant reservations transactional #1101

Description

@doublewhy

Gap Claim

When a concurrent participant batch fails, reservation rollback can release another batch's reservation or leave the in-memory snapshot partially mutated. Backend exception text may also escape through participant diagnostics.

Existing Surface Audit

Reviewed participant scheduling, reservation acquisition, batch dispatch, rollback and snapshot restoration, per-participant concurrency tests, and the scheduler fixes currently bundled into PR #1086.

Scope

OpenRAE runtime reliability only. Requirement: RUN-308.

Chosen Architecture

Treat each concurrent batch as one transaction: retain the pre-batch snapshot, bind reservations to that batch, withdraw only its reservations on failure, restore the snapshot exactly, and expose a stable redacted diagnostic rather than native backend exception text.

Verification Plan

Exercise overlapping batches, partial dispatch failure, rollback after another batch acquires a reservation, snapshot identity, retry, deterministic outcomes, and secret-bearing backend exceptions. Keep request-admission and MCP changes outside this issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions