runAgent model calls have no timeout/abort — a stalled Lyzr response hangs the request (and the journey stage) indefinitely

[nandanNM]

Summary

runAgent() (src/server/api/gitagent.ts) awaits the model stream with no
deadline and no AbortSignal, so a stalled Lyzr response never resolves and
never throws. The request — and, via the run engine, the journey stage — hangs
indefinitely, and the server-side call leaks.

Evidence

src/server/api/gitagent.ts

• L279-289 — query({ … }) is called with no timeout/abort.
• L283 — replaceBuiltinTools: true (single-shot, no tools).
• L284 — maxTurns: 1.
• L295 — the response is consumed with an unbounded for await (const msg of result).
• L214-241 — opts exposes no signal / timeoutMs, so callers can't bound it either.

SDK @open-gitagent/gitagent/dist

• sdk.js:62 — query()'s AbortController defaults to a fresh one and is only
  fired by a manual generator.abort() (sdk.js:522). There is no wall-clock
  timer. runAgent never calls .abort() and sets no timer.

Why the existing runtime.timeout does NOT cover this

Every agent.yaml declares runtime: { timeout: 180 }, which looks like it
bounds a run — it does not. That value is only used as the built-in CLI/sandbox
tools' per-command timeout, and only when built-in tools are enabled:

• SDK sdk.js:135-137

  if (!options.replaceBuiltinTools) {
    tools = createBuiltinTools({ dir, timeout: loaded.manifest.runtime.timeout, ... });
  }

[stealthwhizz]

@nandanNM
Thanks for taking a look! I went through the analysis, and I agree with the diagnosis.

The issue seems to be that query() only supports an optional AbortController, but when one isn't provided it creates a new controller without any deadline. As a result, if the LLM request stalls, the for await loop in chat-history.ts can block indefinitely.

The proposed fix also looks clean and consistent with the existing codebase:

• Add timeoutMs?: number to QueryOptions.
• In query(), create an internal timeout that calls abort() when timeoutMs expires, and make sure the timer is cleared in finally.
• Update chat-history.ts to pass a reasonable timeout (around 30–60 seconds) so history summarization can't hang forever.
• Since withTimeout already exists in src/mcp/manager.ts, it would be great to extract it into a shared utility instead of introducing another timeout implementation.

This keeps timeout handling centralized, avoids duplicated logic, and also gives SDK consumers an easy way to opt into request timeouts.

Overall, I think this is a worthwhile fix especially because a single stalled LLM request can otherwise leave the async flow waiting indefinitely with no recovery path.

Fix it and create a PR

[stealthwhizz]

@ahmadalguydi Please dont send a PR to any issue, request for the issue from next time. Thanks

@nandanNM Sorry