nanocoai/nanoclaw · warning

Failed to clear orphan processing claims

Error message

Failed to clear orphan processing claims

What it means

The 60s sweep failed to delete orphan processing_ack claims in a session's outbound.db. Stale claims can make the host consider the session 'processing' when it isn't, delaying wakeups until a later successful sweep.

Source

Thrown at src/host-sweep.ts:352

        messageId: msg.id,
        tries: msg.tries,
        backoffMs,
        reason,
      });
    }
  }

  // Drop the orphan 'processing' rows. Without this, the next sweep tick
  // would re-read them, see the old status_changed timestamp, conclude the
  // freshly respawned container is stuck, and SIGKILL it before its
  // agent-runner has a chance to run clearStaleProcessingAcks() on startup.
  try {
    const cleared = outDb.deleteOrphanProcessingClaims();
    if (cleared > 0) {
      log.info('Cleared orphan processing claims', { sessionId: session.id, cleared, reason });
    }
  } catch (err) {
    log.warn('Failed to clear orphan processing claims', { sessionId: session.id, err });
  }
}

View on GitHub (pinned to 294ef2aee8)

Solutions

  1. Usually self-heals on the next 60s sweep — wait one cycle first
  2. If persistent, check the session DB isn't locked: inspect data/v2-sessions/<group>/<session>/outbound.db with a quick read query
  3. Verify the session directory exists and the mount is healthy
Defensive patterns

Strategy: retry

Try / catch

try { outDb.deleteOrphanProcessingClaims(); } catch { /* retried on next 60s sweep */ }

Prevention

When it happens

Trigger: outDb.deleteOrphanProcessingClaims() throws — SQLite I/O error, DB locked by the container writing concurrently, or a cross-mount visibility hiccup.

Common situations: Container mid-write during the sweep (lock contention), disk issues, or a session directory removed while sweeping.

Related errors


AI-assisted analysis of nanocoai/nanoclaw@294ef2aee8 (2026-08-28). Data as JSON: /api/errors/c56b1e53545f1b35. Report an issue: GitHub.