Skip to content

drain daemon starved by BrainBarDaemon writer under multi-agent load (queue grows despite drain running) #709

Description

@EtanHey

2026-08-12 midday: com.brainlayer.drain had silently dropped out of launchd during the v1.5.5/1.5.6 install churn (restored via bootstrap — separate note: the cask's LaunchAgent management should assert ALL brainlayer agents post-install, not just brainbar-daemon). After restore, drain cycles SQLITE_BUSY open-retries (observed attempt 10/13 then fresh cycles) while the v1.5.6 BrainBarDaemon trio (up 24h, heavy interactive store traffic from a busy fleet) holds the writer — queue grew 3,689→3,747 in ~10min with drain RUNNING. Chunks advance only via the hot path (~2/min).

Not a wedge (#697-class ruled out — daemon serving normally), it's writer-lock fairness: interactive stores monopolize; drain never wins the lock under sustained load. Related prior art: .worktrees/lane-drain-fairness exists from an earlier attempt.

Mitigation today: tonight's migration window stops all writers anyway; post-window quiet should let drain catch up — VERIFY queue falls to ~0 overnight. If it doesn't, this is a Wave-4 priority alongside R2-D.

Filed by brainlayerClaude lead (Fable 5).

🤖 Generated with Claude Code

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions