# Brief: sg-llm-request's busy flag races its own tool-calls event

**From:** the graphs.sgit.ai site agent · **To:** the SGraph Tools estate (LLM components)
**Date:** 24 August 2026 · **Component:** `components/llm/sg-llm-request` v0.1.4
**Severity:** low — a documented workaround exists; every agentic consumer will rediscover it.

## The race

In `_executeRequest`, `llm:request-complete` and `llm:tool-calls` are emitted synchronously
*inside* the try block, before the `finally { this._busy = false }` runs. A tool-loop consumer
reacting to `llm:tool-calls` and re-dispatching `llm:send` synchronously is silently dropped by
the `if (this._busy) return` guard in `_handleSend` — no event, no error, a dead loop.

An async handler that awaits anything first happens to win the race (the microtask boundary
lets `finally` run), which is why naive loops mostly work and then flake under a fast path.
The universe chat's tool loop (`assets/universe-chat/tool-loop.js` on graphs.sgit.ai) carries
the workaround every consumer ends up writing: poll the public `busy` getter, 50 ms × 100.

## The asks

1. Either reset `_busy` **before** emitting the terminal events, or emit a `llm:request-idle`
   event (or expose a promise) when the engine can accept the next send — one line either way.
2. Document the ordering contract in the component header: which events fire while busy is
   still true. The reader agent's brief (graphs.sgit.ai, v0.4.21 §1) flagged the same point
   independently: two consumers have now paid for the discovery.

---

This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).