Repository navigation
Server: make webhook timeout and retry limits configurable #519
Description
Summary
Allow each webhook to set its own request timeout and maximum delivery attempts. Webhooks that omit these options should continue using the current defaults, with existing retry behavior preserved.
Motivation
Different webhook endpoints can have different response times and reliability needs. A slow endpoint may need a longer timeout, while an endpoint that recovers quickly may benefit from a different attempt limit. Per-webhook settings let operators tune delivery without changing behavior for existing configurations.
Proposed options
Add optional timeout and maximum-attempt settings to the webhook configuration. Use names and units consistent with the existing configuration style.
- Timeout: Maximum time to wait for one delivery attempt.
- Maximum attempts: Total number of delivery attempts, including the initial request.
When either option is omitted, use its current default.
Requirements
- Apply the configured timeout independently to each webhook delivery attempt.
- Stop retrying after that webhook reaches its configured maximum number of attempts.
- Preserve current retry rules, including which responses or errors are retryable and the existing delay or backoff behavior.
- Keep current defaults for webhooks that do not specify the new options.
- Validate option values and return clear configuration errors for invalid values, such as non-positive timeouts or attempt counts.
- Avoid changing unrelated webhook delivery behavior.
Tests
Add or update tests to cover:
- Existing defaults when the options are omitted.
- Different timeout and attempt limits for separate webhooks.
- The configured timeout applying to each delivery attempt.
- Retry stopping at the configured attempt limit.
- Existing retry rules and delays remaining unchanged.
- Invalid option values being rejected with clear errors.
Documentation
Document the new per-webhook options, their units, valid ranges, and defaults. Include a configuration example and explain that the attempt limit includes the initial delivery request.
Activity
Saifjafri212213 commentedon Oct 31, 2026
@anurag629 I'd like to take this one if it's free (@piyusshhjangid, you filed it, so say if you want it yourself). I have one free slot (ogcops#362 is in review). Could you assign it to me? I'll start once it shows as assigned.
piyusshhjangid commentedon Oct 31, 2026
hey @anurag629 I’ve drafted the issue with the per-webhook options, defaults, validation, retry behavior, tests, and documentation requirements. If the scope looks right, could you add the appropriate labels and assign it to me?
Sorry, @Saifjafri212213—I’d like to take this one on. Thanks!
anurag629 commentedon Oct 31, 2026
@piyusshhjangid yours, and labeled. You filed both #519 and #520, but with #477 open you have one slot. You asked for this one first, so #520 goes to Saif, who asked for both before you.
Pointers:
WebhookConfiginpackages/core/src/types.ts:215. Call themtimeoutMsandmaxAttempts, to matchtoolTimeoutMsandrateLimit.windowMs.DEFAULT_WEBHOOK_TIMEOUT_MS(packages/server/src/webhook.ts:13) andMAX_ATTEMPTS(webhook.ts:18).webhook.ts:119-151: the attempts at 119 and 150, andAbortSignal.timeout(this.timeoutMs)at 137. Read them per webhook there.WebhookDispatcherconstructor (webhook.ts:92), so a bad value fails when the server starts, like the URL check.maxAttemptsshould be a whole number from 1 to 10, andtimeoutMsa positive finite number.@chatcops/coreand@chatcops/server. Runpnpm apiand commit the snapshot, and add the options to the webhooks section ofwebsite/src/content/docs/server/setup.mdx.Finish #504 first.