Why the scan is partial? Is there timeout?

[SlavikCA]

I ran the scan on one of my project, using uncensored GLM 5.3 running locally. The LLM speed is not very fast:

• PP 500 t/s
• TG 15 t/s

Got this results:

  Keygraph  v3.5.0

  ███████╗██╗  ██╗ █████╗ ███╗   ██╗███╗   ██╗ ██████╗ ███╗   ██╗
  ██╔════╝██║  ██║██╔══██╗████╗  ██║████╗  ██║██╔═══██╗████╗  ██║
  ███████╗███████║███████║██╔██╗ ██║██╔██╗ ██║██║   ██║██╔██╗ ██║
  ╚════██║██╔══██║██╔══██║██║╚██╗██║██║╚██╗██║██║   ██║██║╚██╗██║
  ███████║██║  ██║██║  ██║██║ ╚████║██║ ╚████║╚██████╔╝██║ ╚████║
  ╚══════╝╚═╝  ╚═╝╚═╝  ╚═╝╚═╝  ╚═══╝╚═╝  ╚═══╝ ╚═════╝ ╚═╝  ╚═══╝

  AI Pentester for Web Apps and APIs

  -Authorized Security Testing Only-


  Scan: hotel-acloud-app_shannon-1793329500969 partial · 3h 50m

  ●  Preflight                 8s
  ·  Authentication            skipped
  ●  Pre-Recon                 38m 56s
  ●  Recon                     47m 55s
  ✗  Vulnerability Analysis    failed
       ✗ injection         failed · This scan step could not be completed.
       ✗ xss               failed · This scan step could not be completed.
       ✗ auth              failed · This scan step could not be completed.
       ✗ ssrf              failed · This scan step could not be completed.
       ● authz             1h 6m
  ✗  Exploitation              failed
       ✗ injection         failed · This scan step could not be completed.
       ✗ xss               failed · This scan step could not be completed.
       ✗ auth              failed · This scan step could not be completed.
       ✗ ssrf              failed · This scan step could not be completed.
       ● authz             56m 37s + 2m 55s
  ●  Reporting                 17m 25s

  Time Taken   3h 50m

  Why this scan is partial:
    - Injection could not be fully assessed. The other classes completed. Re-running this workspace retries only the part that failed.
    - Cross-Site Scripting could not be fully assessed. The other classes completed. Re-running this workspace retries only the part that failed.
    - Authentication could not be fully assessed. The other classes completed. Re-running this workspace retries only the part that failed.
    - Server-Side Request Forgery could not be fully assessed. The other classes completed. Re-running this workspace retries only the part that failed.

full log:
https://gist.github.com/SlavikCA/95c5a38df11d2b2fb8349a4eaaf67e99

I asked LLM to inspect logs, and it's conclusion:

What the log shows
All five vulnerability-class agents started simultaneously at 04:32:07:

text

[04:32:07] [AGENT] ssrf-vuln: Starting
[04:32:07] [AGENT] auth-vuln: Starting
[04:32:07] [AGENT] injection-vuln: Starting
[04:32:07] [AGENT] xss-vuln: Starting
[04:32:07] [AGENT] authz-vuln: Starting
Then at exactly 05:34:24, four of them were killed together.

Only authz-vuln survived and completed its full cycle (analysis → exploitation → report), 
which is why the final report contains only Authorization findings.

Why they all died at once
The identical failure timestamp and identical elapsed duration (62m 16s from a simultaneous start) 
strongly suggest an external/common abort — e.g., a wall-clock limit enforced 
by the orchestrator/runtime on in-flight agents, or a runner-level hiccup. 
It was not caused by what each agent individually found: 
organic errors would produce varied durations and error types. 
The platform itself couldn't classify it ("unknown"), 
and no retry attempt was logged afterward for any of the four.

Aggravating factors visible in the log that inflated runtimes toward whatever limit existed:

Heavy parallel fan-out — every main agent spawned multiple subagent tasks plus live curl probes. 
Flaky tool execution under contention — many instant bash failed (0ms/1ms) calls early on 
(e.g., pre-recon subagents' find ... commands failing in ~1ms) 
that had to be retried with explicit timeouts, burning turns.
Slow/failing network operations — repeated bash slow (21.8s) warnings; 
several attempts to download test media (w3schools/test-videos.co.uk) failed outright, forcing retries.

[SlavikCA]

Is MAX_OPERATION_TIMEOUT_MS here

shannon/apps/worker/src/ai/sast/capella/tools/confinement.ts

Line 15 in b9744f6

const MAX_OPERATION_TIMEOUT_MS = 60_000;

control the timeout?

Is it possible to configure it to different value?

Also, is it possible to configure so that agents are not running in parallel, but sequentally?

[dgesteves]

No, MAX_OPERATION_TIMEOUT_MS isn't involved. It caps a single file operation (60 s) inside the Agentic SAST tools (confinement.ts#L11-L15). It doesn't apply to the vuln/exploit agents, and it's a constant, not a setting.

The limits on each vuln/exploit agent are the Temporal activity options in workflows.ts#L92-L121: 2 hours start-to-close, a 60-minute heartbeat timeout (the agent heartbeats every 2 s), and up to 50 attempts with the first retry after 5 minutes. None of them is configurable. Your agents stopped at 62 minutes, and a Temporal timeout gets retried, which would show up in workflow.log as injection-vuln: Starting (attempt 2).

What ends a class with no retry is a model error Shannon treats as permanent. isProviderRetryable retries 5xx, 429, timeouts and dropped connections; most 4xx errors and context-size rejections are final. Four agents failing in the same second while authz carried on points at the model server failing every in-flight request at that moment, not at a Shannon timer.

The unknown in the log doesn't mean Shannon couldn't classify it: every model failure is logged with that category (turn-error.ts#L24-L35). The real detail is in error.log, where each line has retryable and a provider object with providerCategory (context_limit, transport, overloaded, ...). Copy it before resuming, since a resume resets the deliverables folder to the last checkpoint:

cd ~/.shannon/workspaces/hotel-acloud-app_shannon-1793329500969/.shannon   # ./workspaces/... for a source build
grep -E '\[ERROR\]|Starting \(attempt' workflow.log
cp deliverables/error.log ~/shannon-error.log

If it happens again, set SHANNON_DEBUG_PROVIDER_ERRORS=1 for the run. The CLI passes it to the worker, and error.log then also keeps the first 500 characters of the server's error text (turn-error.ts#L73-L82).

Sequential: not in v3.5.0. Five lanes at once is hardcoded as MAX_CONCURRENT_PIPELINES = 5 (workflows.ts#L186) with no env or config override, so changing it means editing that line in a source build. Resuming with -w hotel-acloud-app_shannon-1793329500969 reruns only the four failed classes.

I checked all of this against the v3.5.0 source; I didn't run a scan.

[hariom123-dev]

@dgesteves is spot on regarding the architecture—Keygraph didn't time out; your local LLM server rejected the requests, which Keygraph interpreted as a fatal, non-retryable error.

Given that you are running GLM 5.3 locally and four agents died at the exact same second after 62 minutes of execution, you almost certainly hit a GPU Out of Memory (OOM) crash or a hard context-length limit on your local inference server (e.g., vLLM, llama.cpp, or Ollama).

Here is exactly what happened and how to fix it:

The Root Cause
Keygraph agents accumulate massive amounts of context over an hour of scanning. With MAX_CONCURRENT_PIPELINES = 5, your local LLM server was maintaining 5 massive, independent context windows simultaneously. At 62 minutes, the total context size across those parallel requests exceeded your local server's configured max context or your GPU's VRAM.
The inference server threw a 400 Bad Request (Context Exceeded) or 500 Internal Server Error (CUDA OOM) for all active connections. authz-vuln likely survived because it happened to be between LLM calls at that exact millisecond.

Action: Check your local LLM server's console output (not Keygraph's logs) around the 62-minute mark. You will see the exact crash there.

How to run sequentially (The Code Fix)
Since you are using a local LLM, running 5 heavy agents concurrently will constantly OOM your hardware. To force sequential execution, you need to modify the hardcoded limit in the source code.

Open shannon/apps/worker/src/workflows.ts

Locate line ~186 (depending on your exact v3.5.0 commit):

TypeScript
const MAX_CONCURRENT_PIPELINES = 5;
Change it to:

TypeScript
const MAX_CONCURRENT_PIPELINES = 1;
Rebuild the worker (typically npm run build or pnpm build in the worker directory, or running the root build script).

Resuming your scan
Once you've patched the concurrency to 1 and restarted the Keygraph worker, you do not need to start over.
Run your scan again using the workspace flag:keygraph scan -w hotel-acloud-app_shannon-1793329500969

Because you patched it to sequential mode, Keygraph will resume and queue the 4 failed agents (injection, xss, auth, ssrf) to run one at a time. This will keep your local LLM's VRAM usage completely stable, and your scan will finish successfully (albeit taking longer in wall-clock time).