starred/documenso

Fork 0

mirror of https://github.com/documenso/documenso.git synced 2026-04-25 13:55:59 +03:00

[GH-ISSUE #2313] Webhook Retry Loop Causing Unlimited Calls, Server Storage Exhaustion & Massive DB Growth #657

New issue

Open

opened 2026-02-26 18:47:56 +03:00 by kerem · 3 comments

kerem commented

2026-02-26 18:47:56 +03:00

Owner

Originally created by @khanakhun on GitHub (Dec 10, 2025).
Original GitHub issue: https://github.com/documenso/documenso/issues/2313

Describe the improvement you are suggesting in detail

Environment:

Documenso Self-Hosted

Running on Ubuntu Server (Docker Deployment)

Version: 24

Issue Summary

When configuring a webhook endpoint in Documenso, the system repeatedly retries webhook deliveries without any upper limit. If my backend temporarily returns a 400 response, Documenso continues to resend the same webhook event indefinitely — even after disabling the webhook in the dashboard.

Overnight, this behavior resulted in:

~120 GB of log files generated

Over 1,000,000+ records inserted into the WebhookCall table

Server disk becoming completely full

Application downtime due to storage exhaustion

This indicates the webhook retry mechanism lacks a maximum retry count, exponential backoff, or a stop condition.

Steps to Reproduce

Set up a webhook URL in Documenso (Self-Hosted).

Trigger an event (e.g., document status update).

Make the receiving backend return a 400 error.

Observe that Documenso sends continuous webhook calls without stopping.

Disable the webhook in the dashboard requests still continue.

Expected Behavior

Webhook retries should stop after a reasonable number of attempts (e.g., max 5–10 attempts).

Exponential backoff should be applied to avoid overload.

When a webhook is disabled, Documenso should immediately stop retrying pending deliveries.

The system should not generate unbounded WebhookCall entries.

Actual Behavior

Webhooks retry endlessly when the destination returns 400.

Disabling the webhook does not stop the retries.

Server storage becomes full due to excessive logs and millions of DB records.

Requires manual database cleanup.

Impact

This behavior creates a high-risk scenario for anyone self-hosting Documenso:

Potential server crash due to full disk

Database bloat

Increased hosting costs

Service downtime

Risk of data corruption from forced resets

Request / Proposed Fix

Implement a maximum retry limit for webhook deliveries.

Apply exponential backoff between retries.

Ensure webhook disable state is respected immediately.

Provide a cleanup or pruning mechanism for old WebhookCall entries.

Additional Information & Alternatives (optional)

No response

Do you want to work on this improvement?

Please check the boxes that apply to this improvement suggestion.

I have searched the existing issues and improvement suggestions to avoid duplication.
I have provided a clear description of the improvement being suggested.
I have explained the rationale behind this improvement.
I have included any relevant technical details or design suggestions.
I understand that this is a suggestion and that there is no guarantee of implementation.

Originally created by @khanakhun on GitHub (Dec 10, 2025). Original GitHub issue: https://github.com/documenso/documenso/issues/2313 ### Describe the improvement you are suggesting in detail Environment: Documenso Self-Hosted Running on Ubuntu Server (Docker Deployment) Version: 24 Issue Summary When configuring a webhook endpoint in Documenso, the system repeatedly retries webhook deliveries without any upper limit. If my backend temporarily returns a 400 response, Documenso continues to resend the same webhook event indefinitely — even after disabling the webhook in the dashboard. Overnight, this behavior resulted in: ~120 GB of log files generated Over 1,000,000+ records inserted into the WebhookCall table Server disk becoming completely full Application downtime due to storage exhaustion This indicates the webhook retry mechanism lacks a maximum retry count, exponential backoff, or a stop condition. Steps to Reproduce Set up a webhook URL in Documenso (Self-Hosted). Trigger an event (e.g., document status update). Make the receiving backend return a 400 error. Observe that Documenso sends continuous webhook calls without stopping. Disable the webhook in the dashboard requests still continue. Expected Behavior Webhook retries should stop after a reasonable number of attempts (e.g., max 5–10 attempts). Exponential backoff should be applied to avoid overload. When a webhook is disabled, Documenso should immediately stop retrying pending deliveries. The system should not generate unbounded WebhookCall entries. Actual Behavior Webhooks retry endlessly when the destination returns 400. Disabling the webhook does not stop the retries. Server storage becomes full due to excessive logs and millions of DB records. Requires manual database cleanup. Impact This behavior creates a high-risk scenario for anyone self-hosting Documenso: Potential server crash due to full disk Database bloat Increased hosting costs Service downtime Risk of data corruption from forced resets Request / Proposed Fix Implement a maximum retry limit for webhook deliveries. Apply exponential backoff between retries. Ensure webhook disable state is respected immediately. Provide a cleanup or pruning mechanism for old WebhookCall entries. ### Additional Information & Alternatives (optional) _No response_ ### Do you want to work on this improvement? No ### Please check the boxes that apply to this improvement suggestion. - [ ] I have searched the existing issues and improvement suggestions to avoid duplication. - [x] I have provided a clear description of the improvement being suggested. - [ ] I have explained the rationale behind this improvement. - [x] I have included any relevant technical details or design suggestions. - [ ] I understand that this is a suggestion and that there is no guarantee of implementation.

kerem added the

status: triage

label

2026-02-26 18:47:56 +03:00

kerem commented

2026-02-26 18:47:57 +03:00

Author

Owner

@coderabbitai[bot] commented on GitHub (Dec 10, 2025):

📝 CodeRabbit Plan Mode

Generate an implementation plan and agent prompts for this issue.

Create Plan

Examples

🔗 Similar Issues

Related Issues

👤 Suggested Assignees

erueda1
Tschatscher85
el3ctrician
JArdissone
Novapixel1010

🧪 Issue enrichment is currently in early access.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

@coderabbitai[bot] commented on GitHub (Dec 10, 2025):  ## 📝 CodeRabbit Plan Mode Generate an implementation plan and agent prompts for this issue. - [ ]  Create Plan <details> <summary>Examples</summary> - [Example 1](https://github.com/coderabbitai/git-worktree-runner/issues/29#issuecomment-3589134556) - [Example 2](https://github.com/coderabbitai/git-worktree-runner/issues/12#issuecomment-3606665167) </details> ## 🔗 Similar Issues **Related Issues** - [documenso/documenso#1857](https://github.com/documenso/documenso/issues/1857) - [documenso/documenso#2060](https://github.com/documenso/documenso/issues/2060) - [documenso/documenso#2023](https://github.com/documenso/documenso/issues/2023) - [documenso/documenso#2061](https://github.com/documenso/documenso/issues/2061) - [documenso/documenso#1763](https://github.com/documenso/documenso/issues/1763) ## 👤 Suggested Assignees - erueda1 - Tschatscher85 - el3ctrician - JArdissone - Novapixel1010 --- <details> <summary> 🧪 Issue enrichment is currently in early access.</summary> To disable automatic issue enrichment, add the following to your `.coderabbit.yaml`: ```yaml issue_enrichment: auto_enrich: enabled: false ``` </details>

kerem commented

2026-02-26 18:47:57 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Dec 10, 2025):

Thank you for opening your first issue and for being a part of the open signing revolution!

One of our team members will review it and get back to you as soon as it possible 💚

Meanwhile, please feel free to hop into our community in Discord

@github-actions[bot] commented on GitHub (Dec 10, 2025): Thank you for opening your first issue and for being a part of the open signing revolution! <br /> One of our team members will review it and get back to you as soon as it possible 💚 <br /> Meanwhile, please feel free to hop into our community in [Discord](https://documen.so/discord)

kerem commented

2026-02-26 18:47:57 +03:00

Author

Owner

@fridezlucas commented on GitHub (Feb 10, 2026):

+1 on this. I'm experiencing the exact same issue on my self-hosted instance. Failed webhooks are retried immediately and indefinitely with no backoff and no max retry limit, which eventually overwhelms the server and causes log files to grow out of control.
At a minimum, it would be great to have:

A configurable max retry count (e.g., 5–10 attempts)
Exponential backoff between retries
Retries actually stopping when a webhook is disabled

This is a real operational risk for anyone self-hosting Documenso. Would love to see this addressed — happy to help test any fix.

@fridezlucas commented on GitHub (Feb 10, 2026): +1 on this. I'm experiencing the exact same issue on my self-hosted instance. Failed webhooks are retried immediately and indefinitely with no backoff and no max retry limit, which eventually overwhelms the server and causes log files to grow out of control. At a minimum, it would be great to have: A configurable max retry count (e.g., 5–10 attempts) Exponential backoff between retries Retries actually stopping when a webhook is disabled This is a real operational risk for anyone self-hosting Documenso. Would love to see this addressed — happy to help test any fix.

kerem referenced this issue

2026-02-26 19:31:52 +03:00

[PR #657] [MERGED] chore: custom command menu shortcut text for macOS #1107

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/documenso#657

No description provided.

Rows
Columns