mcp: a query made during a first index that runs past 900 s fails with a bare 'Error executing tool' #1557

Symptom

A query made through the MCP server while the repository's first axiomcode index is still running (no graph.sqlite yet, for example while a cold rule compile runs) waits on the build lock, and after 900 s comes back as a bare Error executing tool axiomcode_impact: no answer, no mention of the running build, no advice to retry. The same query made while the build takes less than 900 s answers normally and prints a graph build is already running ... waiting for it. The CLI waits as long as the build takes.

Reproduction

Measured on 0.1.3 at 0df257c. A pom.xml with groupId app, plus two files.

src/main/java/app/orders/OrderService.java:

package app.orders;

public class OrderService {
    public int total(int qty, int price) {
        return qty * price;
    }
}

src/main/java/app/orders/OrderController.java:

package app.orders;

public class OrderController {
    private final OrderService service = new OrderService();

    public int checkout(int qty) {
        return service.total(qty, 5);
    }
}

A slow first build is stood in for by holding the build lock the way axiomcode-build does:

mkdir -p .axiomcode
python3 -c "import fcntl,time; f=open('.axiomcode/build.lock','w'); fcntl.flock(f,fcntl.LOCK_EX); time.sleep(1000)" &

Then MCP axiomcode_impact(targets=["OrderService.total"], repo=<abs path>).

• Lock held 1000 s: after about 900 s, Error executing tool axiomcode_impact. The server's own payload is TimeoutExpired: Command '['bash', '.../axiomcode', 'impact', ...]' timed out after 900 seconds, and an axiomcode-build for the repository is left behind, still waiting on the lock.
• Control, lock held 300 s: the same call answers after 300 s ([resolved] OrderController.checkout ... OrderController.java:7), and the CLI does the same.

Root cause

plugins/axiomcode/mcp/server.py:41-52: run() calls subprocess.run(..., timeout=900) and catches only OSError, so subprocess.TimeoutExpired escapes the tool. The wait it times out is unbounded: with no graph, ax_contract.py:383-389 (ensure_graph) starts a second axiomcode-build, which blocks on the lock at axiomcode-build:81-84. Killing the bash child on timeout does not stop that build.

Expected

A query that finds a build running and no graph yet returns, well within the tool timeout, a message naming the running build and saying to retry once it finishes.