Problem Statement

SessionCompressorV2 currently retries subtree lock acquisition in an unbounded loop under contention.
In busy environments, this can cause session commit/memory extraction to block indefinitely, leading to unpredictable latency and operational risk.
There is currently no way for operators to tune retry pacing or cap retry attempts.

Proposed Solution

Add configurable lock-acquisition controls for memory v2 extraction, including:

• retry interval (seconds)

• maximum retry attempts (or total timeout)

• clear behavior when limit is exceeded (e.g., raise timeout error, skip extraction, or configurable fail mode)

Also add:

• telemetry/logging for retry count and timeout events

• tests for bounded retry behavior and failure path

Alternatives Considered

• Keep infinite retry (status quo)

  • Simple but can block indefinitely.

• Use a fixed global lock timeout only

  • Better than infinite retry, but less flexible for varied workloads.

• Force fail-fast without retries

  • Low latency, but may be too aggressive during short contention spikes.

Feature Area

Session Management

Use Case

In production multi-session deployments, concurrent commits may contend on memory directories.
Teams need predictable latency and failure behavior, instead of unbounded waiting, to maintain SLOs and avoid stuck commits.

Example API (Optional)

{
  "memory": {
    "version": "v2",
    "v2_lock_retry_interval_seconds": 0.2,
    "v2_lock_max_retries": 10
  }
}

Additional Context

This is a reliability/operability enhancement for memory v2 extraction flow.
It helps prevent indefinite blocking and makes lock contention behavior observable and tunable.

Contribution

• I am willing to contribute to implementing this feature