centralizing ratelimiter logic

[Mzack9999]

Proposed changes

Supersedes #5667

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

• Refactor
  • Centralized rate-limiting logic into a shared utility, ensuring consistent behavior across the app.
  • Streamlined handling of “unlimited” rate limits (when limit or duration is zero) for predictable performance.
  • Reduced duplicated setup code, improving maintainability without changing user-facing behavior or configuration.

[coderabbitai]

Walkthrough

Centralizes rate limiter creation by introducing utils.GetRateLimiter and replacing direct ratelimit constructions in runner, config, and multi components. The new helper returns either an unlimited limiter or a timed limiter based on inputs. No public API changes except the new exported utility function.

Changes

Cohort / File(s)	Summary
Centralize rate limiter initialization internal/runner/runner.go, lib/config.go, lib/multi.go	Replaced direct ratelimit construction with utils.GetRateLimiter(...); updated imports accordingly. Logic around usage unchanged.
New utility for rate limiter pkg/utils/utils.go	Added exported GetRateLimiter(ctx context.Context, maxTokens int, duration time.Duration) *ratelimit.Limiter returning unlimited when maxTokens==0 or duration==0; otherwise delegates to ratelimit.New(...).

Sequence Diagram(s)

sequenceDiagram
    participant Caller
    participant Runner/Lib
    participant Utils as utils.GetRateLimiter
    participant RL as ratelimit pkg

    Caller->>Runner/Lib: initialize components
    Runner/Lib->>Utils: GetRateLimiter(ctx, rate, duration)
    alt rate==0 or duration==0
        Utils-->>Runner/Lib: return unlimited limiter
        note over Utils,Runner/Lib: Zero-value inputs yield no rate limiting
    else
        Utils->>RL: New(ctx, uint(rate), duration)
        RL-->>Utils: limiter instance
        Utils-->>Runner/Lib: return configured limiter
    end
    Runner/Lib-->>Caller: proceed with obtained limiter

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Pre-merge checks (3 passed)

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The title "centralizing ratelimiter logic" succinctly and accurately summarizes the main change (centralizing rate limiter creation into a utils helper) and is concise, focused, and relevant to the diff. It clearly conveys the primary intent without extraneous detail, making it useful for quick scanning of PR history.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

Poem

I twitch my whiskers, code in flight,
One helper now to set the rate just right.
Fewer branches, cleaner trail,
Hops through utils never fail.
With limits tuned by time and count—
I thump approval: concise, no bloat, paramount! 🐇✨

✨ Finishing touches

• 📝 Generate Docstrings

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch maint-rate-unlimit

---

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: 0

🧹 Nitpick comments (2)

lib/multi.go (1)

56-56: Avoid drift: rely on utils.GetRateLimiter for defaulting

You still set RateLimitDuration locally when zero; if you accept centralizing defaulting in utils.GetRateLimiter (see suggested change), drop the local default to keep behavior uniform across runner/multi/config.

Follow-up (after updating utils.GetRateLimiter as proposed):

-	if opts.RateLimit > 0 && opts.RateLimitDuration == 0 {
-		opts.RateLimitDuration = time.Second
-	}

lib/config.go (1)

184-185: Confirm semantics: duration==0 now yields unlimited via utils.GetRateLimiter

With the new helper, passing (maxTokens > 0, duration == 0) results in an unlimited limiter, which may differ from prior behavior. If the intended policy is “default to 1s when duration is zero,” either adopt the centralized defaulting in utils.GetRateLimiter (preferred) or add the same default here for consistency.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 46555bc and e1dfa1b.

⛔ Files ignored due to path filters (1)

• .github/auto_assign.yml is excluded by !**/*.yml

📒 Files selected for processing (4)

• internal/runner/runner.go (1 hunks)
• lib/config.go (2 hunks)
• lib/multi.go (2 hunks)
• pkg/utils/utils.go (2 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

**/*.go

📄 CodeRabbit inference engine (CLAUDE.md)

**/*.go: Format Go code using go fmt
Run static analysis with go vet

Files:

• pkg/utils/utils.go
• internal/runner/runner.go
• lib/config.go
• lib/multi.go

🧬 Code graph analysis (4)

pkg/utils/utils.go (1)

internal/runner/runner.go (1)

• New (109-394)

internal/runner/runner.go (1)

pkg/utils/utils.go (1)

• GetRateLimiter (80-85)

lib/config.go (1)

pkg/utils/utils.go (1)

• GetRateLimiter (80-85)

lib/multi.go (1)

pkg/utils/utils.go (1)

• GetRateLimiter (80-85)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)

• GitHub Check: Tests (macOS-latest)
• GitHub Check: Tests (windows-latest)
• GitHub Check: Tests (ubuntu-latest)

🔇 Additional comments (2)

pkg/utils/utils.go (1)

78-85: Harden limiter creation: guard negatives and centralize duration defaulting

Treat negative/zero maxTokens as unlimited and default non-positive durations to 1s; remove duplicated per-callsite defaults.

-// GetRateLimiter returns a rate limiter with the given max tokens and duration
-// if maxTokens is 0 or duration is 0, it returns an unlimited rate limiter
 func GetRateLimiter(ctx context.Context, maxTokens int, duration time.Duration) *ratelimit.Limiter {
-	if maxTokens == 0 || duration == 0 {
-		return ratelimit.NewUnlimited(ctx)
-	}
-	return ratelimit.New(ctx, uint(maxTokens), duration)
+	// Policy:
+	//   - maxTokens <= 0 => unlimited
+	//   - duration <= 0  => defaults to 1s
+	if maxTokens <= 0 {
+		return ratelimit.NewUnlimited(ctx)
+	}
+	if duration <= 0 {
+		duration = time.Second
+	}
+	return ratelimit.New(ctx, uint(maxTokens), duration)
 }

Update/remove duplicated duration-defaulting at these call sites:

• internal/runner/runner.go — remove the opts.RateLimitDuration == 0 -> time.Second block (≈ lines 384–386).
• lib/multi.go — remove the opts.RateLimitDuration == 0 -> time.Second block (≈ lines 53–55).
• lib/sdk_private.go — replace the manual branch (currently setting RateLimitDuration and calling ratelimit.New/Unlimited, ≈ lines 224–231) with utils.GetRateLimiter(...) to keep semantics consistent.

Confirm API/SDK semantics: WithGlobalRateLimitCtx (lib/config.go:179–186) currently passes duration through; after this change duration <= 0 will be treated as 1s (not “unlimited”) — validate that this is the intended SDK behavior and update docs if necessary.

internal/runner/runner.go (1)

387-387: LGTM: centralized limiter initialization

Using utils.GetRateLimiter here simplifies the logic and keeps behavior consistent with other components.

[Mzack9999]

@coderabbitai resolve
@coderabbitai make an issue for this PR

[coderabbitai]

🧩 Analysis chain

I'll resolve the review comments and create an issue for this PR.

@Mzack9999 I've created an issue to track this PR and will resolve all the review comments.

---

🏁 Script executed:

#!/bin/bash
# Create an issue for PR #6472 - centralizing ratelimiter logic
gh issue create \
  --title "Centralize rate limiter logic implementation" \
  --body "This issue tracks the implementation of centralized rate limiter logic in Nuclei.

**Background:**
This supersedes PR #5667 and aims to consolidate rate limiter creation logic into a unified utility function.

**Changes needed:**
- Replace explicit rate limiter initialization logic across the codebase
- Centralize rate limiting behavior in pkg/utils/utils.go with GetRateLimiter function
- Ensure consistent handling of unlimited vs timed rate limiters

**Related PR:** https://github.com/projectdiscovery/nuclei/pull/6472
**Requested by:** @Mzack9999

**Files affected:**
- internal/runner/runner.go
- lib/config.go  
- lib/multi.go
- pkg/utils/utils.go" \
  --assignee Mzack9999

Length of output: 54

---

@Mzack9999 Done! I've resolved all review comments and created issue #6474 to track this PR: #6474

The issue includes the background, proposed changes, and references this PR as requested.

✅ Actions performed

Comments resolved.