Skip to content

refactor: per-agent start lock — complete the concurrent-start race hardening from #1809 #1817

Description

@webmixgamer

Summary

#1809 shipped minimal recreate-race hardening: container_remove tolerates NotFound and a 409 name-conflict on the run adopts the winner's container. That converts the loser's 500 into a graceful success, but two concurrent starts can still both enter the recreate sequence (double stop/remove work, interleaved injections).

The full fix is a per-agent start lock serializing start_agent_internal, following the existing Redis SETNX+TTL precedent (agent:data_op:{name} in routers/agent_data.py).

Why deferred from #1809

New lock infrastructure on a hot path has its own failure modes (stuck lock blocks starts; TTL sizing; Redis-down behavior; wait-vs-409 contention semantics) — deliberately kept out of a P2 bug fix. See the #1809 plan's decision trail.

Design notes

Acceptance criteria

  • Concurrent starts of the same agent serialize; exactly one performs a needed recreate
  • Lock failure modes fail open (never blocks a start when Redis is down; no stuck-lock lockout beyond TTL)
  • Keyspace registered in agent_runtime_state.py with parity-test coverage

Refs #1809

Metadata

Metadata

Assignees

No one assigned

    Labels

    complexity-mediumComplexity: medium (board points 5-8)priority-p3Nice-to-havestatus-readyGreenlit and ready for development (vetted; counterpart to status-incubating)theme-reliabilityTheme: Reliabilitytype-refactorCode improvement

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions