ReferenceError: document is not defined

Not specified by the original author.

TL;DR

Fix this in Conveyor evidence import by doing this first: re-export the document as a searchable PDF with a real text layer instead of a scanned image, keep the file name free of special characters, and re-import that copy into the compliance room. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

document parse failure

Use this when

• The operation fails with this exact problem: document parse failure.
• The same failure repeats on retry with unchanged inputs.
• An audit, review, or request is blocked until this item completes.

Not for this skill when

• The message is a platform outage notice or a general sign-in failure. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in Conveyor evidence import, and copy the full message plus the item, account, or request involved into the run notes. Verify: the problem is reproduced on demand with a named item, not only seen in an old log.
2. Apply the specific fix for this problem: re-export the document as a searchable PDF with a real text layer instead of a scanned image, keep the file name free of special characters, and re-import that copy into the compliance room. Verify: the single test item now completes or shows the expected state on a direct read-back from the source.
3. Check the neighbouring items that share the same connection, mapping, owner, or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Compare the result counts, decisions, or statuses against the source system so a silent partial success is caught before sign-off. Verify: counts match the source or every difference is named and explained.
5. Rerun the original operation on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
6. Record the fix, the triggering input, and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied, and the evidence of success.

Why it happens

Conveyor extracts text during import and fails on image-only scans or malformed PDFs, so the document never becomes available to the questionnaire it was meant to answer.

Variant phrasings

Conveyor evidence import failed error document parse failure compliance room

The verbatim form searchers paste from the console or ticket. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix this failure in practice

The how-to phrasing for the same failure. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Troubleshooting the symptom-first form

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

Compatibility: Conveyor evidence import at current versions, plus the source systems the query names; no extra tooling beyond the platform console or API access needed to verify counts.

Provenance

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

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

Thread query: Conveyor evidence import failed error document parse failure compliance room

TL;DR: Fix this in Conveyor evidence import by doing this first: re-export the document as a searchable PDF with a real text layer instead of a scanned image, keep the file name free of special characters, and re-import that copy into the compliance room. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

Not specified by the original author.

TL;DR: Atlas Search is separate from Vector Search. Create a search index with the right analyzers, then query with $search. Wrong analyzer = missed results. - Index builds are async; poll until READY before querying. - $search must be the first stage, like $vectorSearch. Verify A query for a known term returns the known document at the top with a searchScore, and an explain on the query shows the search index in use.

The fix

Atlas Search index

Create the index

Atlas UI: Search tab, Create Search Index, JSON editor. Or via driver/CLI:

db.products.createSearchIndex("default", {
  mappings: { dynamic: true }
});

dynamic: true indexes everything with default analyzers: fine for starting, wasteful at scale. For production, define explicit mappings:

db.products.createSearchIndex("product_idx", {
  mappings: {
    dynamic: false,
    fields: {
      name: { type: "string", analyzer: "lucene.standard" },
      description: { type: "string", analyzer: "lucene.english" },
      price: { type: "number" }
    }
  }
});

Query

db.products.aggregate([
  { $search: {
      index: "product_idx",
      text: { query: "wireless headphones", path: ["name", "description"] }
  } },
  { $limit: 10 },
  { $project: { name: 1, score: { $meta: "searchScore" } } }
]);

Rules

• The index type here is search, not vectorSearch. They are different indexes for different query operators ($search vs $vectorSearch).
• Pick analyzers per field language: the english analyzer stems ("running" matches "run"); standard does not. Wrong analyzer = missed results.
• Index builds are async; poll until READY before querying.
• $search must be the first stage, like $vectorSearch.

Verify

A query for a known term returns the known document at the top with a searchScore, and an explain on the query shows the search index in use.

When to use this

• This covers exactly what the title says: Atlas.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Atlas; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current Atlas behavior.

Atlas Search index creation (mappings, analyzers, dynamic vs explicit) and $search query shape per https://www.mongodb.com/docs/search/indexes/manage-indexes/, verified 2026-09-26.

Not specified by the original author.

TL;DR

Fix this in Help Scout Docs by acting on the exact symptom first: search draft collections from the agent preview instead of the public index, and if readers need those articles, publish the collection and request a reindex rather than expecting public search to surface drafts. 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.

Help Scout Docs search ignores articles inside draft collections

Use this when

• Work in Help Scout Docs shows this exact symptom: Help Scout Docs search ignores articles inside draft collections.
• 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 Help Scout Docs, 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: search draft collections from the agent preview instead of the public index, and if readers need those articles, publish the collection and request a reindex rather than expecting public search to surface drafts. 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 Help Scout Docs 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

Help Scout Docs search ignores articles inside draft collections

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 - Help Scout Docs search ignores articles inside draft collections

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

Help Scout Docs 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

Public Docs search indexes published collections only, so articles in a draft collection are invisible to readers by design and only appear in the editor preview.

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: Help Scout Docs 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_cWReNwYpCRpZJTvjf5ojpQ

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

Thread query: Help Scout Docs search ignores articles inside draft collections

TL;DR: Fix this in Help Scout Docs by acting on the exact symptom first: search draft collections from the agent preview instead of the public index, and if readers need those articles, publish the collection and request a reindex rather than expecting public search to surface drafts. 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.