root/fusion
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

record the detector audit: gridlock and stuck-task are keeps, with evidence (#2581)

Browse Source 
Answering the review question *“does gridlock detection still have a
job?”* — with evidence rather than assumption, and recording it so the
question is not re-opened by someone reading the name.

**No behaviour change.** Comments only.

## Gridlock detector — KEEP

`GridlockEvent.reasons` is typed `"dependency" | "overlap"`. It detects
**dependency deadlock** and **file-scope overlap deadlock** via the
scheduler’s `pathsOverlap` / `filterPathsByIgnoreList`. That has nothing
to do with limiters arbitrating against each other — two tasks can still
block on a dependency cycle or a shared file scope no matter how many
agents the operator allows.

The hypothesis that gridlock ≈ competing limiters deadlocking was
reasonable from the name, and wrong.

## Stuck-task detector — KEEP

Detects a stuck **agent** — a live session repeating the same tool call,
or emitting no activity signal — via tool fingerprints and inactivity
windows. Orthogonal to how many agents may run: a single agent on an
unlimited board can still wedge.

## Evidence

Measured for both: **zero** references to `maxConcurrent` /
`maxWorktrees` / `semaphore` / `capacity` / `slot`. Both are live and
wired — gridlock via `project-engine.ts → notifier.notifyGridlock`,
stuck-task via `in-process-runtime.ts`.

The note lives in each file because the natural reading of “gridlock” is
“limiters deadlocking”, and deleting a live detector on that reading
would remove real coverage silently. Each note states the question a
future cleanup should actually ask — *is dependency/overlap deadlock
still possible?* — rather than *is capacity simpler now?*

`pnpm lint` clean · engine `tsc` clean · `pnpm test:gate` green ·
detector suites **108/108**.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
gsxdsm
2026-07-29 23:34:30 -07:00
committed by GitHub
parent 15b21dead1
commit 152fedbd32
2 changed files with 35 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
packages/engine/src/gridlock-detector.ts
View File

@@ -1,3 +1,25 @@
/*
FNXC:CapacityModel 2026-07-29-15:00 (capacity-simplification audit — KEEP, with evidence):
ASKED AND ANSWERED: does gridlock detection still have a job once capacity is two
numbers and the competing limiters are gone?
YES. "Gridlock" here has nothing to do with limiters arbitrating against each other.
`GridlockEvent.reasons` is typed `"dependency" | "overlap"` — it detects DEPENDENCY
deadlock and FILE-SCOPE OVERLAP deadlock, using `pathsOverlap` /
`filterPathsByIgnoreList` from the scheduler. Neither is affected by removing the
cross-project cap, the spawn budgets, or the worktree gate: two tasks can still
block each other on a dependency cycle or a shared file scope no matter how many
agents the operator allows.
Measured, not assumed: no CODE in this file references maxConcurrent, maxWorktrees, the shared
semaphore, or any slot/capacity accounting — the only occurrences of those words are in this note.
It is live and wired (project-engine.ts -> notifier.notifyGridlock).
Recorded here because the natural reading of the NAME is "limiters deadlocking", and
deleting a live detector on that reading would remove real coverage silently. If a
future cleanup revisits this, the question to ask is whether dependency and overlap
deadlock are still possible — not whether capacity is simpler.
*/
import type { MissionStore, Task, TaskStore, WorkflowIr } from "@fusion/core";
import { resolveTaskLifecycleColumns } from "@fusion/core";
import { createLogger } from "./logger.js";

13
packages/engine/src/stuck-task-detector.ts
View File

@@ -1,3 +1,16 @@
/*
FNXC:CapacityModel 2026-07-29-15:00 (capacity-simplification audit — KEEP, with evidence):
Audited alongside the gridlock detector while collapsing the capacity model. It is
NOT a capacity component and nothing here changes with the limiters.
This detects a STUCK AGENT — a live session repeating the same tool call, or emitting
no activity signal — via tool fingerprints and inactivity windows. That is orthogonal
to how many agents are permitted to run: a single agent on an unlimited board can
still wedge.
Measured, not assumed: zero references to maxConcurrent / maxWorktrees / semaphore /
capacity / slot in this file. Live and wired (in-process-runtime.ts).
*/
/**
* Stuck Task Detector — monitors in-progress tasks for agent session stagnation.
*