[FEATURE] Add webhook retry mechanism with exponential backoff for failed webhook deliveries

[Abhushan187]

Problem

When a webhook endpoint is temporarily down or returns a non-2xx response, urBackend currently does not retry the delivery. This causes data loss for users relying on webhooks for real-time synchronization (e.g., syncing user signups to CRM, triggering CI pipelines on data changes). A single transient failure permanently drops the event.

---

Proposed Improvement

Implement an automatic retry mechanism with exponential backoff for failed webhook deliveries. The system should:

• Retry failed webhooks up to 5 times with delays: 1s, 2s, 4s, 8s, 16s
• Store retry state in Redis (attempt count, next retry timestamp)
• Use BullMQ to schedule retry jobs asynchronously
• Mark webhooks as "failed permanently" after max retries and notify the project owner via email
• Expose retry status in the dashboard (pending / retrying / failed / delivered)
• Respect a Retry-After header if the endpoint returns 429

---

Expected Impact

• Better reliability for webhook-dependent integrations
• Reduced data loss from transient network failures
• Improved user trust in urBackend's event delivery guarantees
• Better long-term scalability with BullMQ-based job scheduling

---

Possible Implementation

• Add webhookRetryQueue in apps/public-api/services/ using BullMQ
• Extend WebhookLog schema with retryCount, maxRetries, nextRetryAt, finalStatus
• Add processWebhookRetry worker that re-attempts delivery with exponential backoff
• Add POST /api/webhooks/{id}/retry manual retry endpoint for dashboard
• Update dashboard UI to show retry timeline and status badges
• Write tests for retry logic, backoff timing, and max-retry exhaustion

---

I'm GSSoC'26 contributor, Please assign this task to me!

[Abhushan187]

/assign

[SHRUTIDHEPE]

/assign