fix(loader): compile requests during validation

[dwisiswant0]

Proposed changes

Do not let parsed template cache hits bypass
protocol compilation, making -validate reject
templates with runtime compilation errors.

Fixes #7602

Proof

Checklist

• Pull request is created against the dev branch
• All checks passed (lint, unit/integration/regression tests etc.) with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

Summary by CodeRabbit

• Bug Fixes

  • Improved template validation so runtime parsing errors are detected reliably.
  • Invalid templates now correctly fail validation and report actionable error details.

• Tests

  • Added coverage for templates containing invalid regular-expression extractor settings.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 29402ddc-bd1f-4d18-a445-72e490311559

📥 Commits

Reviewing files that changed from the base of the PR and between 7936ec3 and 479c818.

📒 Files selected for processing (2)

• pkg/catalog/loader/loader.go
• pkg/catalog/loader/loader_test.go

---

Walkthrough

Template validation now parses each template directly instead of reusing cached parsed templates, allowing runtime compilation errors to fail validation. A regression test covers an invalid regex extractor group.

Changes

Runtime validation

Layer / File(s)	Summary
Direct template parsing and regression coverage pkg/catalog/loader/loader.go, pkg/catalog/loader/loader_test.go	Validation directly parses templates, preserves existing error handling, and verifies that runtime regex compilation errors cause ValidateTemplates() to fail.

Estimated code review effort: 3 (Moderate) | ~15–30 minutes

Possibly related PRs

• projectdiscovery/nuclei#7603: Changes the same template validation path and covers regex extractor compilation errors.
• projectdiscovery/nuclei#7612: Updates regex extractor compilation to reject invalid capture-group indices.

Suggested reviewers: mzack9999, dogancanbakir

Poem

I’m a rabbit, hopping through the queue,
Catching runtime errors before they’re due.
Cached paths aside, each template gets a tune,
Bad regex groups are spotted soon.
Validation now thumps its paw: “Pass or fail!”

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: compiling requests during template validation.
Linked Issues check	✅ Passed	The code now validates runtime compilation errors during -validate and the new test covers the reported extractor group failure.[#7602]
Out of Scope Changes check	✅ Passed	The changes stay focused on template validation and the associated regression test, with no clear unrelated additions.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch dwisiswant0/fix/loader/compile-requests-during-validation

---

_{Comment @coderabbitai help to get the list of available commands.}

[DPS0340]

Verified #7616 fixes #7602 — built it and ran the original repro:

$ nuclei -t /tmp/bad.yaml -validate
[ERR] Error occurred parsing template /tmp/bad.yaml: could not compile request:
      could not compile operators: could not compile extractor:
      regex extractor group must be >= 0, got -1
[FTL] Could not validate templates: errors occurred during template validation

Before, that same file returned All templates validated successfully and exit 0.

Your approach is better than mine. #7603 pointed validation at the compiled cache; #7616 removes the cache lookup entirely so templates.Parse always runs. Mine kept a branch that could go stale — if a third cache were added later, the same class of bug comes back. Yours has nothing to keep in sync, and it is a net −9 lines.

Thanks for picking it up. Nothing outstanding from me on this one.