Proposal: fix implementation-orchestrator — add deduplication check when adopting existing workers to prevent duplicate workers per PR #5774

New issue

Open

opened 2026-04-09 09:20:36 +00:00 by HAL9000 · 0 comments

HAL9000 commented

2026-04-09 09:20:36 +00:00

Owner

Agent Improvement Proposal

Pattern Detected

Type: workflow_fix
Affected Agent: implementation-orchestrator
Evidence: Issue #5638 (Implementation Pool Tracking Cycle 4, 2026-04-09 07:55 UTC) shows PR #5271 with TWO workers simultaneously:

Active workers table: PR #5271 | ses_28f16f3f3ffe... | ACTIVE (adopted)
Additional Workers Detected section: PR #5271 | ses_28ec6c2f9ffe... | ACTIVE

Two different session IDs are both assigned to PR #5271. The orchestrator adopted an existing worker AND dispatched a new one for the same PR.

Proposed Change

In the worker adoption logic, before dispatching a new worker for a PR, check if an adopted worker already exists for that PR in the active workers table. Specifically:

When scanning existing sessions to adopt workers, build a set of adopted_pr_numbers
When dispatching new workers for PRs, skip any PR that already has an adopted worker
Add a deduplication check: if pr_number in active_workers: skip dispatch

The pseudocode change would be:

# When adopting existing workers:
for session in existing_sessions:
    if session.title matches "[AUTO-IMP] worker-pr:<N>":
        pr_number = extract_pr_number(session.title)
        active_workers[pr_number] = session.id  # Mark as adopted

# When dispatching new workers:
for pr in prs_needing_workers:
    if pr.number in active_workers:
        continue  # Already has a worker (adopted or dispatched)
    dispatch_new_worker(pr)

Expected Impact

No more duplicate workers per PR
Freed worker slots for other PRs or issues
Reduced risk of conflicting changes from two workers on the same PR
More accurate worker utilization metrics

Risk Assessment

Low risk. The change only adds a guard condition before dispatching workers. The worst case is that an adopted worker is stale/dead, in which case the PR would not get a new worker until the next monitoring cycle detects the stale session and removes it. This is acceptable behavior — the async-agent-monitor already handles stale session detection.

This is a proposal from the agent evolver. A human must approve this issue before the change will be implemented. To approve: remove the needs feedback label, add State/Verified, or comment with approval.

Automated by CleverAgents Bot
Supervisor: Agent Evolver | Agent: agent-evolver

## Agent Improvement Proposal ### Pattern Detected **Type**: workflow_fix **Affected Agent**: implementation-orchestrator **Evidence**: Issue #5638 (Implementation Pool Tracking Cycle 4, 2026-04-09 07:55 UTC) shows PR #5271 with TWO workers simultaneously: - Active workers table: `PR #5271 | ses_28f16f3f3ffe... | ACTIVE (adopted)` - Additional Workers Detected section: `PR #5271 | ses_28ec6c2f9ffe... | ACTIVE` Two different session IDs are both assigned to PR #5271. The orchestrator adopted an existing worker AND dispatched a new one for the same PR. ### Proposed Change In the worker adoption logic, before dispatching a new worker for a PR, check if an adopted worker already exists for that PR in the active workers table. Specifically: 1. When scanning existing sessions to adopt workers, build a set of `adopted_pr_numbers` 2. When dispatching new workers for PRs, skip any PR that already has an adopted worker 3. Add a deduplication check: `if pr_number in active_workers: skip dispatch` The pseudocode change would be: ``` # When adopting existing workers: for session in existing_sessions: if session.title matches "[AUTO-IMP] worker-pr:<N>": pr_number = extract_pr_number(session.title) active_workers[pr_number] = session.id # Mark as adopted # When dispatching new workers: for pr in prs_needing_workers: if pr.number in active_workers: continue # Already has a worker (adopted or dispatched) dispatch_new_worker(pr) ``` ### Expected Impact - No more duplicate workers per PR - Freed worker slots for other PRs or issues - Reduced risk of conflicting changes from two workers on the same PR - More accurate worker utilization metrics ### Risk Assessment Low risk. The change only adds a guard condition before dispatching workers. The worst case is that an adopted worker is stale/dead, in which case the PR would not get a new worker until the next monitoring cycle detects the stale session and removes it. This is acceptable behavior — the async-agent-monitor already handles stale session detection. --- *This is a proposal from the agent evolver. A human must approve this issue before the change will be implemented. To approve: remove the `needs feedback` label, add `State/Verified`, or comment with approval.* --- **Automated by CleverAgents Bot** Supervisor: Agent Evolver | Agent: agent-evolver

Rows
Columns