fix: replace panic with error handling in template loader

[areebahmeddd]

Proposed changes

Fixes #6674

Replaced a panic with proper error handling in the template loader when GetDialersWithId() returns nil, since this can occur in non-scanning paths where dialers aren’t initialized.

Proof

• make test - all unit tests pass
• make vet - passes with no issues
• make build - compiles successfully

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)

/claim #6674

Summary by CodeRabbit

• Bug Fixes
  • Enhanced error handling for template loading operations. Previously, certain failure scenarios could cause crashes or be silently ignored; errors are now properly captured and reported to prevent application instability.

[coderabbitai]

Walkthrough

The changes add proper error handling to template loading functions in the catalog loader package. LoadTemplates and LoadTemplatesWithTags now return errors instead of panicking when dialers are not found. Callers have been updated throughout the codebase to handle the new error returns.

Changes

Cohort / File(s)	Summary
Template Loader API Changes pkg/catalog/loader/loader.go	Updated LoadTemplates and LoadTemplatesWithTags to return ([]*templates.Template, error). Replaced panic with fmt.Errorf when dialers not found. Functions now propagate errors up the call chain.
Error Handling in Callers internal/runner/lazy.go, pkg/protocols/common/automaticscan/util.go	Updated to capture and handle errors from LoadTemplates and LoadTemplatesWithTags. Errors are wrapped with context-specific messages before returning.
Benchmark Test Updates pkg/catalog/loader/loader_bench_test.go	Updated all LoadTemplates call sites to handle the new two-value return signature using blank identifiers.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 No more panics, just errors so clear,
Templates load without much fear,
The dialers dance in harmony now,
Graceful returns—take a bow!
Error handling hops along the way,
Making the loader code so slay! 🌸

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Linked Issues check	✅ Passed	The PR fully addresses issue #6674 by replacing the panic with fmt.Errorf when dialers are missing, updating function signatures to return errors, and propagating errors through callers in lazy.go and automaticscan/util.go.
Out of Scope Changes check	✅ Passed	All changes are directly related to replacing panic with error handling in template loading. Updates to function signatures, error returns, and caller sites are all necessary and in-scope for implementing the panic replacement fix.
Title check	✅ Passed	The title 'replace panic()' is directly related to the main objective of the PR, which is to replace a panic with proper error handling in the template loader.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In `@pkg/catalog/loader/loader_bench_test.go`:
- Around line 73-75: The benchmark loop is ignoring errors returned by
store.LoadTemplates which can hide failures; update each b.Loop() block (where
store.LoadTemplates([]string{config.DefaultConfig.TemplatesDirectory}) is
called) to capture the returned error and fail the benchmark on error (e.g., if
err := store.LoadTemplates(...); err != nil { b.Fatalf("LoadTemplates failed:
%v", err) }) so the benchmark stops and surfaces the real failure instead of
measuring an error path.

In `@pkg/catalog/loader/loader.go`:
- Around line 334-339: The Load method currently ignores the error from
LoadTemplates which can hide failures; update Store.Load (the method receiver
Store.Load) to return an error, call store.LoadTemplates(store.finalTemplates)
and capture its error, set store.templates only on success, call
store.LoadWorkflows(store.finalWorkflows) afterwards, and propagate any error
returned (i.e., return the error instead of discarding it) so callers can handle
failures instead of getting an empty store.templates; adjust callers of
Store.Load accordingly to handle the new error return.

[areebahmeddd]

gentle ping! @dwisiswant0 @dogancanbakir @Mzack9999

[areebahmeddd]

gentle ping.. @DhiyaneshGeek

[DhiyaneshGeek]

Hi @areebahmeddd

Kindly refrain from tagging everyone in the comments , the team will review short

Thanks

[areebahmeddd]

gentle ping! it’s been about a month. i’ve noticed a lot of prs coming in for this issue. any chance this could get a review soon? (p.s the failing tests are flaky in nature)

cc @dwisiswant0 @Mzack9999 @DhiyaneshGeek

[areebahmeddd]

i noticed that a pr (#6825) raised after mine, with the same changes, was reviewed and merged first. this reflects poorly on the open-source spirit at projectdiscovery and feels borderline biased scam.

while many use ai (including myself), i took the time to understand the context, run tests, and follow pr standards. yet, the team showed significant negligence.

cc @dogancanbakir @dwisiswant0 @DhiyaneshGeek @knakul853