Context
Every webhook attempt writes a row in src/modules/webhooks/webhooks.service.ts:
await db.webhookDelivery.create({
data: { webhookId: webhook.id, statusCode, success, payload: payload as object, response: responseText },
});Each row stores the full JSON payload plus up to 1 KB of response body, and nothing ever deletes them. One row per tip per enabled webhook, forever. A creator with three webhooks generates three rows per tip, and the retry work proposed in a separate issue will multiply that further.
This is the table that quietly becomes the largest in the database and starts driving storage cost and backup times, long before anyone thinks to look at it.
What to do
Add retention. Straightforward approach:
- a scheduled prune deleting successful deliveries older than N days (30 is a reasonable default), keeping failures longer for debugging
- make the window configurable via env, documented in
.env.example and the README
- delete in batches so a large first run doesn't lock the table
Check that webhookDelivery has an index supporting the prune predicate — without one the delete degrades badly as the table grows.
Acceptance criteria
New to Novatip? Here's how to contribute
Everything below is covered in more detail in the Novatip contributing guide — the full version lives at novatip-docs/CONTRIBUTING.md. Please read it before opening a PR.
1. Claim the issue. Comment below saying you'd like to work on it, and wait to be assigned before you start. This avoids two people building the same thing.
2. Fork this repository using the Fork button at the top right of Novatip/novatip-backend.
3. Clone your fork and add the upstream remote:
git clone https://github.com/YOUR_USERNAME/novatip-backend
cd novatip-backend
git remote add upstream https://github.com/Novatip/novatip-backend
4. Create a feature branch off main — never commit directly to main:
git checkout main
git pull upstream main
git checkout -b fix/short-description
5. Set up your local environment. Follow the local development guide to get the stack running.
6. Make your change, then run the checks before pushing:
npm run lint
npm run typecheck
npm run build
7. Commit using conventional commits — feat:, fix:, docs:, test:, chore:, refactor::
git commit -m "fix: short description of what changed"
git push origin fix/short-description
8. Open a pull request against Novatip/novatip-backend:main. Keep it focused on this one issue, and reference it in the description so it closes automatically:
Questions are welcome — ask them on this issue rather than getting stuck. Please don't report security vulnerabilities in public issues; see SECURITY.md instead.
Context
Every webhook attempt writes a row in
src/modules/webhooks/webhooks.service.ts:Each row stores the full JSON payload plus up to 1 KB of response body, and nothing ever deletes them. One row per tip per enabled webhook, forever. A creator with three webhooks generates three rows per tip, and the retry work proposed in a separate issue will multiply that further.
This is the table that quietly becomes the largest in the database and starts driving storage cost and backup times, long before anyone thinks to look at it.
What to do
Add retention. Straightforward approach:
.env.exampleand the READMECheck that
webhookDeliveryhas an index supporting the prune predicate — without one the delete degrades badly as the table grows.Acceptance criteria
New to Novatip? Here's how to contribute
Everything below is covered in more detail in the Novatip contributing guide — the full version lives at novatip-docs/CONTRIBUTING.md. Please read it before opening a PR.
1. Claim the issue. Comment below saying you'd like to work on it, and wait to be assigned before you start. This avoids two people building the same thing.
2. Fork this repository using the Fork button at the top right of Novatip/novatip-backend.
3. Clone your fork and add the upstream remote:
git clone https://github.com/YOUR_USERNAME/novatip-backend cd novatip-backend git remote add upstream https://github.com/Novatip/novatip-backend4. Create a feature branch off
main— never commit directly tomain:5. Set up your local environment. Follow the local development guide to get the stack running.
6. Make your change, then run the checks before pushing:
7. Commit using conventional commits —
feat:,fix:,docs:,test:,chore:,refactor::git commit -m "fix: short description of what changed" git push origin fix/short-description8. Open a pull request against
Novatip/novatip-backend:main. Keep it focused on this one issue, and reference it in the description so it closes automatically:Questions are welcome — ask them on this issue rather than getting stuck. Please don't report security vulnerabilities in public issues; see SECURITY.md instead.