feat(webhooks): implement adaptive polling in WebhookProcessorService

[Vswaroop04]

Summary

• Replaces the fixed setInterval(10s) with a setTimeout-based self-scheduling loop
• Updates processRetries() to return a boolean indicating whether any deliveries were found
• Introduces adaptive polling:
  • 2s delay when retries are present (fast path)
  • 10s delay when the queue is empty (base path, unchanged behavior)
• Adds an isShuttingDown flag to prevent re-scheduling after onModuleDestroy

Why

Webhook retries follow an exponential backoff pattern with short initial delays (1s, 2s, 4s). With the previous fixed 10s polling interval, retries could sit idle for up to 10 seconds before being processed.

This adaptive approach reduces that delay during active retry periods while maintaining the same database load during idle periods.

Test Plan

• Run pnpm test and confirm existing webhook tests pass
• Manually trigger a failing webhook delivery and verify retries are picked up in ~2s instead of ~10s
• Confirm that no polling occurs after the service shuts down

[Vswaroop04]

I have read the CLA Document and I hereby sign the CLA

[KIvanow]

Hey @Vswaroop04 - good idea and the implementation logic is sound, but I can't merge this without test coverage on the new scheduling behaviour. A few things to address:

1. Tests for the adaptive loop. The schedule closure, the isShuttingDown guard, and the error-path fallback to BASE are all untested. Jest fake timers + a spy on processRetries returning true/false/rejecting would cover the three cases without spinning real timers.
2. Check off the test plan. Please confirm pnpm test is green and the manual retry paths were verified before marking ready for review.
3. Minor cleanup. The initial run and the schedule inner function have identical .then()/.catch() chains written out twice. Consider calling schedule(0) for the initial kick-off instead - one code path, fully testable.

[Vswaroop04]

Hey @Vswaroop04 - good idea and the implementation logic is sound, but I can't merge this without test coverage on the new scheduling behaviour. A few things to address:

1. Tests for the adaptive loop. The schedule closure, the isShuttingDown guard, and the error-path fallback to BASE are all untested. Jest fake timers + a spy on processRetries returning true/false/rejecting would cover the three cases without spinning real timers.

2. Check off the test plan. Please confirm pnpm test is green and the manual retry paths were verified before marking ready for review.

3. Minor cleanup. The initial run and the schedule inner function have identical .then()/.catch() chains written out twice. Consider calling schedule(0) for the initial kick-off instead - one code path, fully testable.

Done