Increase webhook retry attempts from 3 to 5

[eabdelmoneim]

• Changes webhook delivery attempts from 3 to 8
• Keeps exponential backoff with 5-second base delay
• Total retry window increases from ~15s to ~10m 35s
• Provides better resilience for temporary outages, deployments, and restarts

Timeline:

• Attempt 1: 0s
• Attempt 2: +5s (5s total)
• Attempt 3: +10s (15s total)
• Attempt 4: +20s (35s total)
• Attempt 5: +40s (1m 15s total)
• Attempt 6: +1m 20s (2m 35s total)
• Attempt 7: +2m 40s (5m 15s total)
• Attempt 8: +5m 20s (10m 35s total)

🤖 Generated with Claude Code

Changes

• Linear: https://linear.app/thirdweb/issue/INC-217/amex-mtls-webhook-intermittent-500-errors-engine-cloud-prod
• Here is the problem being solved.
• Here are the changes made.

How this PR will be tested

• Open the dashboard and click X. Result: A modal should appear.
• Call the /foo/bar API. Result: Returns 200 with "baz" in the response body.

Output

(Example: Screenshot/GIF for UI changes, cURL output for API changes)

---

PR-Codex overview

This PR focuses on modifying the attempts property in the defaultJobOptions of the send-webhook-queue.ts file to increase the number of retry attempts for failed jobs.

Detailed summary

• Changed the attempts value from 3 to 5 in the defaultJobOptions object.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

Summary by CodeRabbit

• Chores
  • Increased webhook retry attempts from 3 to 5 to improve delivery reliability.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Increased the default retry attempts for the SendWebhookQueue from 3 to 5 in the BullMQ queue configuration; exponential backoff with a 5-second base delay remains unchanged and no control-flow or API changes were made.

Changes

Cohort / File(s)	Summary
Webhook Queue Configuration src/worker/queues/send-webhook-queue.ts	Increased BullMQ retry attempts for webhook jobs from 3 to 5 (exponential backoff with 5s base delay unchanged).

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

• Review src/worker/queues/send-webhook-queue.ts to confirm only the retry count changed and backoff semantics remain intact.

Pre-merge checks and finishing touches

❌ Failed checks (2 warnings, 1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description contains contradictions: it claims changes from 3 to 8 but PR-Codex shows 3 to 5. Testing checklist is also incomplete/placeholder.	Correct the description to reflect actual change (3 to 5), update retry timeline accordingly, and provide realistic test steps specific to webhook retry behavior.
Title check	⚠️ Warning	The PR title states 'Increase webhook retry attempts from 3 to 5', but the PR objectives and description indicate the actual change is from 3 to 8 attempts. The title is inaccurate and misleading.	Update the PR title to accurately reflect the change: 'Increase webhook retry attempts from 3 to 8' or align the implementation with the stated title of 5 attempts.
Linked Issues check	❓ Inconclusive	The PR partially addresses INC-217 by improving retry resilience, but doesn't directly investigate or resolve the root cause of mTLS/SSL handshake failures.	Clarify whether this retry improvement alone resolves the issue or if root cause investigation (mTLS/networking) is still pending separately.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Out of Scope Changes check	✅ Passed	The change to retry attempts is directly related to addressing webhook delivery resilience mentioned in INC-217, with no extraneous modifications detected.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch ea_change_webhook_retries

---

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

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

src/worker/queues/send-webhook-queue.ts (1)

58-64: Config change is correct; consider broader impact of longer retry window.

The BullMQ config here looks valid: bumping attempts to 8 with the same exponential backoff cleanly achieves the ~10m35s retry window described, and all jobs using this queue will inherit it since they don’t override attempts/backoff in their add() calls.

One thing to double‑check operationally is whether it’s acceptable for all webhook types on this shared send-webhook queue (not just AMEX) to hang around and retry for ~10 minutes before final failure, e.g., for consumers that might prefer faster failure visibility or have stricter latency expectations. If that’s a concern, you might later split queues or make attempts/backoff configurable per integration, but that doesn’t block this PR.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 3b5b14c and 1a11cd2.

📒 Files selected for processing (1)

• src/worker/queues/send-webhook-queue.ts (1 hunks)

⏰ 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). (2)

• GitHub Check: build
• GitHub Check: lint