Found while validating the CrowdStrike integration (#6746). Three tool descriptions were publishing as empty strings in integrations.json and the generated MDX, with no build failure and no warning.
Cause
buildToolDescriptionMap searches only 600 characters forward from the id: match when locating a tool's description. Any tool whose description field sits past that window — long params blocks, long TSDoc, a verbose oauth/hosting config declared before description — yields no match, and the entry is emitted blank rather than erroring.
Why it matters
- It is silent. Nothing fails: not
type-check, not check:audits, not the docs build. The published catalog entry and docs page just lose their description.
- It is position-dependent, so it can appear on an unrelated edit that merely pushes
description further down a file.
- It is repo-wide. CrowdStrike is where it was caught, but any integration with long tool descriptions is likely affected right now.
Suggested fix
Prefer parsing to a bounded regex window — the generator already reads tool source, so resolving description from the AST removes the window entirely. Failing that:
- Raise/remove the window, and
- Fail the build on a blank description rather than emitting an empty string. The silence is the real defect; a wrong description is visible, a missing one is not.
A regression test asserting no generated catalog entry has an empty description would catch every instance repo-wide in one pass.
Related docs-generator defects found in the same batch
Three distinct issues, same component — worth looking at together:
- This one — 600-char window silently blanks descriptions.
- Shared
outputs/params consts vanish from published docs — the generator parses tool source, so extracting duplicated output literals into a shared const deletes those rows from the MDX. query_cases and query_host_groups are missing documented output rows on staging today because of this.
table.mdx divergence — the generator drops a nextCursor row the committed file has, so every regeneration "loses" it and contributors keep reverting the diff by hand.
Escaped \' in a description also truncates the generated MDX cell mid-row (already known, tracked separately) — a lint rule rejecting \' in tool descriptions would close that one.
Found while validating the CrowdStrike integration (#6746). Three tool descriptions were publishing as empty strings in
integrations.jsonand the generated MDX, with no build failure and no warning.Cause
buildToolDescriptionMapsearches only 600 characters forward from theid:match when locating a tool'sdescription. Any tool whosedescriptionfield sits past that window — long params blocks, long TSDoc, a verboseoauth/hostingconfig declared beforedescription— yields no match, and the entry is emitted blank rather than erroring.Why it matters
type-check, notcheck:audits, not the docs build. The published catalog entry and docs page just lose their description.descriptionfurther down a file.Suggested fix
Prefer parsing to a bounded regex window — the generator already reads tool source, so resolving
descriptionfrom the AST removes the window entirely. Failing that:A regression test asserting no generated catalog entry has an empty
descriptionwould catch every instance repo-wide in one pass.Related docs-generator defects found in the same batch
Three distinct issues, same component — worth looking at together:
outputs/paramsconsts vanish from published docs — the generator parses tool source, so extracting duplicated output literals into a shared const deletes those rows from the MDX.query_casesandquery_host_groupsare missing documented output rows onstagingtoday because of this.table.mdxdivergence — the generator drops anextCursorrow the committed file has, so every regeneration "loses" it and contributors keep reverting the diff by hand.Escaped
\'in a description also truncates the generated MDX cell mid-row (already known, tracked separately) — a lint rule rejecting\'in tool descriptions would close that one.