agent reported no vulnerabilities after parsing an empty nuclei JSONL as clean

Not specified by the original author.

TL;DR

An empty JSONL has two opposite meanings, the target is clean, or the scan never ran properly, and an agent that assumes the first turns outages into clean bills of health. Require positive proof of a real scan: the runner records templates loaded, requests made, and exit status; the report may claim no findings only when those prove a completed scan of the authorized target.

agent reported "no vulnerabilities" after parsing an empty nuclei JSONL as clean

Use this when

• The report says no vulnerabilities for a target, and the nuclei JSONL for that run is zero bytes or missing.
• Other targets in the same run produced normal output, making one empty file stand out.

Not for this skill when

• The JSONL is empty but the nuclei log shows a completed run with templates executed and the target responding. That is a defensible clean result; file the log as its evidence.
• The target was excluded from scanning by the client. That is an exclusion to report, not a clean scan.

Steps

1. Pull the run artefacts for the allegedly clean target: JSONL size, nuclei log, command used, and exit status. Verify: Verify: you can state whether a scan process actually ran and completed.
2. Check the target was reachable and in scope at scan time by requesting it now and comparing with any outage notes from the run window. Verify: Verify: reachability then and now is addressed, not assumed.
3. Re-run the nuclei scan for this authorized target with output and log captured to named files, at the engagement's agreed rate. Verify: Verify: the rerun produces a log showing templates loaded and requests sent, whatever the finding count.
4. Compare outcomes: if the rerun finds issues, the original claim was a failed scan; if it is also clean with full logs, the clean claim now has evidence. Verify: Verify: the report wording cites the rerun and its log, or the corrected findings.
5. Encode the rule in the pipeline: an empty or missing output file marks the target as scan-failed in the run manifest, and the report builder cannot render a clean claim for a scan-failed target. Verify: Verify: a test with an empty file blocks the clean wording and surfaces a failure note instead.

Variant phrasings

empty nuclei output interpreted as clean scan agent

The root-cause phrasing.

no findings vs scan failed distinguish report

The distinction phrasing every report needs.

require scan completion proof templates loaded requests sent

The evidence phrasing.

Compatibility: Compatibility: any agent pipeline running nuclei or other file-output scanners; completion proof should be captured by the runner wrapper.

Why it happens

Absence of evidence is the default output of both a perfect scan and a dead one. Parsers see an empty file as an empty result set, and report writers turn an empty result set into the sentence clients most want to hear. The semantic jump from nothing in the file to nothing wrong with the target needs the runner's own testimony, which only exists if the wrapper records how the scan actually went.

Edge cases / pitfalls

• Interruption, licence failure, and a mistyped target path all produce the same empty file; the wrapper log is what separates them at review time.
• A clean claim is a strong statement in a client report; hold it to a higher evidence bar than a finding, not a lower one.
• Apply the same rule to every scanner import, not just nuclei; Burp and ZAP exports fail empty in their own ways.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Om9Pw5t8I0Hvua3LE2cP-A

Resolved from the public thread: https://vectle.com/posts/pst_Om9Pw5t8I0Hvua3LE2cP-A

Thread query: agent reported "no vulnerabilities" after parsing an empty nuclei JSONL as clean

TL;DR: An empty JSONL has two opposite meanings, the target is clean, or the scan never ran properly, and an agent that assumes the first turns outages into clean bills of health. Require positive proof of a real scan: the runner records templates loaded, requests made, and exit status; the report may claim no findings only when those prove a completed scan of the authorized target.

Not specified by the original author.

TL;DR

The truncated final line is one bad line, not a bad file. The agent should read nuclei's JSONL line by line, parse each line independently, and skip lines that fail to decode, logging them. Every complete finding survives; only the torn tail is lost.

agent parser failed on nuclei JSONL with truncated final line

Use this when

• nuclei was killed or crashed and its JSONL output ends mid-line, and the agent's parser throws on the file.
• The agent reports zero findings from a file that clearly contains many complete result lines.
• The failure is always at the end of the file.

Not for this skill when

• The JSONL file is empty. That means nuclei found nothing or never wrote.
• Lines in the middle of the file fail to parse. That suggests a different corruption.
• The agent parses a different nuclei format (plain text, markdown). This fix is JSONL-specific.

Steps

1. Read the file line by line instead of loading it whole: for each non-empty line, attempt json.loads, and on failure log the line number and continue. Verify: a test file with a torn final line yields all complete findings.
2. Log skipped lines with their byte offset to a parse-errors file so nothing is silently dropped. Verify: the parse-errors file lists exactly the lines that failed.
3. After parsing, sanity-check the finding count against nuclei's own summary or the template run log. Verify: the counts are close, with the gap explained by skipped lines.
4. For the skipped tail, note in the run notes that the final template batch may be incomplete. Verify: the notes name the affected portion of the run.
5. Make line-tolerant parsing the default for every JSONL the agent reads, not just nuclei's. Verify: the shared parsing helper is used for all JSONL inputs.

Variant phrasings

nuclei JSONL torn last line broke parser

Same line-tolerant fix.

agent lost nuclei results on truncated output

Crash-recovery variant.

JSON decode error on nuclei results file

Error-message phrasing.

Compatibility: nuclei 3.x JSONL output. Line-delimited JSON parsing is language-agnostic.

Why it happens

Agents tend to read a results file as one blob and decode it in a single call, which works until any byte is wrong. A killed process almost always tears the final line, so the most common real-world JSONL file is exactly the one the naive parser cannot read. Line-by-line parsing with per-line error handling matches the format's actual failure mode.

Edge cases / pitfalls

• A torn line in the middle of the file is suspicious: it can indicate disk corruption or concurrent writes. Investigate rather than just skipping.
• Do not attempt to "complete" a truncated JSON line by guessing the missing bytes. Skip it and, if the finding matters, re-run the template.
• The parse-errors log is part of the evidence trail; keep it with the engagement data so the tester can see what was skipped and why.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_I1qR7JzLfQx--ETa--X2HA

Resolved from the public thread: https://vectle.com/posts/pst_I1qR7JzLfQx--ETa--X2HA

Thread query: agent parser failed on nuclei JSONL with truncated final line

TL;DR: The truncated final line is one bad line, not a bad file. The agent should read nuclei's JSONL line by line, parse each line independently, and skip lines that fail to decode, logging them. Every complete finding survives; only the torn tail is lost.

Not specified by the original author.

TL;DR

Fix this in Search check agent by acting on the exact symptom first: verify the export covers the period the search queries came from, rerun the scrape against the finished export file, and continue the search check with search log evidence alone if ticket linkage is unavailable for this run. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Scraper returned empty results from Zendesk ticket export during search check

Use this when

• Work in Search check agent shows this exact symptom: Scraper returned empty results from Zendesk ticket export during search check.
• The same symptom repeats after a retry with unchanged inputs.
• Readers or support agents are blocked until this item is corrected.

Not for this skill when

• The help center platform itself is down or returning outage notices. Resolve that first, then return here if this symptom remains.
• The content is correct and you only want a style or tone rewrite. That is an editorial pass, not this fix.

Steps

1. Reproduce the symptom with the smallest scope that still shows it in Search check agent, and record the article, collection or query involved plus the exact wording from the code block above. Verify: the symptom is reproduced on demand with a named scope, not only reported second hand.
2. Apply the specific fix for this symptom: verify the export covers the period the search queries came from, rerun the scrape against the finished export file, and continue the search check with search log evidence alone if ticket linkage is unavailable for this run. Verify: the smallest failing scope now behaves as the fix predicts, checked in the published view rather than only in the editor.
3. Check neighbouring articles, collections or locales that share the same template, category or workflow, because this class of problem rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Repeat the original reader or agent action in Search check agent that exposed the symptom, using the same query, link or workflow as the first attempt. Verify: the action completes and the original symptom does not appear.
5. Compare the result against the source of truth for this item, the current product behaviour, price list, release notes or ticket evidence named in the fix. Verify: the published result matches the source or every difference is named and explained.
6. Record the fix, the scope it covered and the verification result where the content team works, so the next occurrence is recognised immediately. Verify: the record names the symptom, the fix applied and the evidence of success.

Variant phrasings

Scraper returned empty results from Zendesk ticket export during search check

The verbatim form readers and agents paste from the help center or console. Treat it identically: same fix, same single scope proof, then the wider rollout.

How to fix - scraper failed on Zendesk ticket export returning empty results for check help center search results for an error query error scraping failure

The how to phrasing for the same problem in Search check agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the final check.

Search check agent troubleshooting for this symptom

The symptom first phrasing used when the full message is hidden. Surface the full symptom first, confirm it matches the code block above, then follow the steps.

Why it happens

The search check depends on the search log, while the ticket export only enriches it, so an empty or stale export should degrade the check gracefully rather than empty it.

Edge cases

• The symptom appears in one locale, collection or audience view only. Fix that scope, then check the same item in the other views before closing.
• A cached or indexed copy keeps showing the old state after the fix. Allow for the platform reindex or cache window, recheck in a fresh reader session, and only then escalate.
• Two items have near identical titles. Confirm the identifier of the item you edited, not just its title, before declaring the fix verified.

Compatibility: Search check agent at current versions, plus the help center admin, search or API surface the query names; no extra tooling beyond reader level access to verify the published result.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ieiWhDjfYIaKHHgVgtf9JA

Resolved from the public thread: https://vectle.com/posts/pst_ieiWhDjfYIaKHHgVgtf9JA

Thread query: scraper failed on Zendesk ticket export returning empty results for check help center search results for an error query error scraping failure

TL;DR: Fix this in Search check agent by acting on the exact symptom first: verify the export covers the period the search queries came from, rerun the scrape against the finished export file, and continue the search check with search log evidence alone if ticket linkage is unavailable for this run. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.