Prolog-RLM context compile is unbounded: compile_timeout missing on both call sites — wedged worker stalls every routed turn indefinitely #121

New issue

Open

opened 2026-09-08 01:16:46 +00:00 by mara · 0 comments

mara commented

2026-09-08 01:16:46 +00:00

Collaborator

Summary

Commit 7c057880 ("fix: route harness direct/complete through the context compiler", PR #92, in main at bba5dcba) made every Prolog-RLM–routed turn perform a blocking, unbounded harness.compile(request) call before dispatching:

Core-loop proxy: plugins/_prolog_rlm/helpers/loop.py:223 — await self.harness.compile(request) with no timeout= argument.
Tool path: plugins/_prolog_rlm/tools/prolog_rlm.py:28 — same, await harness.compile(request) with no timeout.
compile_context_request sends up to 192 units × 12,000 chars of raw host context through the worker transport.

If the shared Prolog worker is slow/unresponsive (busy with a long rlm_direct turn, or wedged — see the pipe-deadlock class of failure), every chat turn and every prolog_rlm tool call hangs indefinitely in the compile phase, before the model is ever reached. This converts the runtime from a verification layer into a single point of failure for the whole loop.

Note this also directly undermines #106's blast-radius analysis: even if the model-call paths get timeouts, the compile path stays unbounded.

Repro

Enable _prolog_rlm routing for a chat.
Pause or wedge the Prolog runtime worker (e.g. while a long direct action is in flight, or SIGSTOP the worker process).
Send a chat message. The turn blocks forever inside PrologRLMModel.unified_turn → _compiled_context, never reaching the inner model; response_callback/streaming never fire.

Expected

Context compilation has a bounded deadline; on timeout or worker failure the turn either falls back to the inner model (like the existing degenerate-turn path at loop.py:173-184) or fails with a clear repairable error.

Suggested fix

Thread self.completion_timeout (or a dedicated, smaller compile_timeout_seconds setting) into both harness.compile(...) call sites.
On TimeoutError/RuntimeFailure from the compile phase, decide policy explicitly: fall back to inner model with a warning (recommended — context compilation is an optimization, not a correctness gate) or surface a repairable error. Today the behavior is an unbounded silent hang, which is the worst option.
Reviewed at main bba5dcba; regression introduced in 7c057880 (2026-09-05).

## Summary Commit `7c057880` ("fix: route harness direct/complete through the context compiler", PR #92, in main at `bba5dcba`) made every Prolog-RLM–routed turn perform a **blocking, unbounded** `harness.compile(request)` call before dispatching: - Core-loop proxy: `plugins/_prolog_rlm/helpers/loop.py:223` — `await self.harness.compile(request)` with **no `timeout=` argument**. - Tool path: `plugins/_prolog_rlm/tools/prolog_rlm.py:28` — same, `await harness.compile(request)` with no timeout. - `compile_context_request` sends up to 192 units × 12,000 chars of raw host context through the worker transport. If the shared Prolog worker is slow/unresponsive (busy with a long `rlm_direct` turn, or wedged — see the pipe-deadlock class of failure), **every chat turn and every `prolog_rlm` tool call hangs indefinitely in the compile phase**, before the model is ever reached. This converts the runtime from a verification layer into a single point of failure for the whole loop. Note this also directly undermines #106's blast-radius analysis: even if the model-call paths get timeouts, the compile path stays unbounded. ## Repro 1. Enable `_prolog_rlm` routing for a chat. 2. Pause or wedge the Prolog runtime worker (e.g. while a long `direct` action is in flight, or SIGSTOP the worker process). 3. Send a chat message. The turn blocks forever inside `PrologRLMModel.unified_turn` → `_compiled_context`, never reaching the inner model; `response_callback`/streaming never fire. ## Expected Context compilation has a bounded deadline; on timeout or worker failure the turn either falls back to the inner model (like the existing degenerate-turn path at `loop.py:173-184`) or fails with a clear repairable error. ## Suggested fix - Thread `self.completion_timeout` (or a dedicated, smaller `compile_timeout_seconds` setting) into both `harness.compile(...)` call sites. - On `TimeoutError`/`RuntimeFailure` from the compile phase, decide policy explicitly: fall back to inner model with a warning (recommended — context compilation is an optimization, not a correctness gate) or surface a repairable error. Today the behavior is an unbounded silent hang, which is the worst option. - Reviewed at main `bba5dcba`; regression introduced in `7c057880` (2026-09-05).

mara added the

bug

label

2026-09-08 01:16:46 +00:00