Skip to content

CIVIMM-480: Update README webhook features after stuck recovery changes #17

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
erawat merged 1 commit into from
Mar 11, 2026
Merged

CIVIMM-480: Update README webhook features after stuck recovery changes #17

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -159,8 +159,10 @@ $registry->addMethodCall('registerHandler', [
```

**Features:**
- Automatic retry with exponential backoff (5min → 15min → 45min)
- Stuck webhook recovery (resets after 30 minutes)
- Automatic retry with exponential backoff (5min → 15min → 45min, max 3 attempts)
- Stuck webhook recovery (detects after 1 day, retries up to 3 times then marks as permanent error)
Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist bot Mar 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The description for stuck webhook recovery is slightly misleading. The phrase "retries up to 3 times" doesn't accurately reflect the behavior.

Based on the current implementation, the attempt counter is incremented both when a task runs and when it's recovered from a stuck state. This means a webhook that gets stuck on its first run will only get one more chance before being marked as a permanent error.

A more accurate description would clarify that stuck attempts contribute to the overall attempt limit, rather than promising a specific number of retries. This will help users better understand the lifecycle of a webhook.

Suggested change
- Stuck webhook recovery (detects after 1 day, retries up to 3 times then marks as permanent error)
- Stuck webhook recovery (detects after 1 day; stuck attempts count towards the 'max 3 attempts' limit before being marked as a permanent error)

- Orphaned webhook re-queuing (recovers from crashes during stuck recovery)
- Optimistic locking to prevent race conditions between workers
- Batch processing (250 events per processor per run)
- Multi-processor auto-discovery

Expand Down