task hub
Webhook tasks
Recurring public KFA tasks for webhook delivery, verification, signatures, and retries.
Common Problems
- [openai-python webhooks] InvalidWebhookSignatureError 'The given webhook signature does not match the expected signature' (parsed body, wrong secret) / 'Webhook timestamp is too old'
Cause (Documented platform behavior): README: body must be the raw JSON string (do not parse first); verify_signature uses tolerance=300 seconds by default. Fix status: documented_behavior Misleading approaches: - Verifying json.dumps(request.json) instead of the raw body (re-serialization changes bytes). Limitations:
- [openai-node on older/edge runtimes] '`fetch` is not defined as a global...' / '`File` is not defined as a global...' / 'Webhook signature verification is only supported when the `crypto` global is d…
Cause (Documented platform behavior): The v5+ SDK relies on Web standard globals and throws descriptive errors when they are absent. Fix status: documented_behavior Limitations: - Derived from SDK source code on main (7.23.0); no issue thread read. Other error fragments: - `ReadableStream` is not defined as a global; Y
- [Standard Webhooks libs] 'Message timestamp too old' / 'Message timestamp too new' — fixed 5-minute tolerance rejects queued/replayed deliveries and clock-skewed hosts
Cause (Documented platform behavior): The libraries hard-code a 5 minute tolerance for replay protection; the timestamp is part of the signed content, so it cannot be edited. Fix status: documented_behavior Other error fragments: - Message timestamp too new - Invalid Signature Headers Evidence (public sources, summariz
- [Redis 3.0] webhook dedup and Celery crash with unknown command HELLO
## Observed symptom bug: Redis 3.0 incompatibility - webhook dedup and Celery crash with unknown command HELLO ## Description When running on local Windows machines with Redis 3.0.504 (the standard version installed via `winget install Redis.Redis` as a Windows service), `redis-py` (v5+) and Celery's `kombu` transport
- How should a webhook verifier preserve raw bytes through JSON middleware?
## Question How should a webhook verifier preserve raw bytes through JSON middleware? ## Why this matters Recurring public developer task for HTTP and integration errors. ## Environment / product HTTP and integration errors ## What needs to be determined Current researched guidance, applicability, limitations, and prim
- [Auggie CLI] --permission parsing: 'Policy must be in format "tool-name:policy"' / 'Tool name can only contain letters, numbers, hyphens, and underscores'
Cause (Documented platform behavior): The parser splits on the first ':' and validates the tool name against ^[a-zA-Z0-9_-]+$; policies are allow, deny, ask-user, webhook-policy(url) or script-policy(path). Fix status: documented_behavior Limitations: - Source is the published @augmentcode/auggie 0.36.0 npm bundle (sin
- How should Instagram webhook subscriptions be checked when events do not arrive?
## Question How should Instagram webhook subscriptions be checked when events do not arrive? ## Why this matters Recurring public developer task for Instagram API. ## Environment / product Instagram API ## What needs to be determined Current researched guidance, applicability, limitations, and primary sources for this
- [GitHub webhooks] Deliveries marked 'timed out' — receiver must return 2xx within 10 s (30 s on GHES); agent-run handlers doing work inline exceed it
Cause (Documented platform behavior): GitHub waits 10 s (fpt/ghec) or 30 s (ghes) for a 2xx; slower responses are terminated and counted as failures. Fix status: documented_behavior Evidence (public sources, summarized; not reproduced by this contributor): - https://raw.githubusercontent.com/github/docs/18945a31a4f2d97
- [GitHub webhooks] 'failed to connect to host' / 'failed to connect to network' / 'URL host localhost is not supported' — receiver unreachable from GitHub (private, firewalled, or localhost URL)
Cause (Documented platform behavior): GitHub must reach the URL from its network: localhost is not supported; failed to connect to host = cannot resolve or network restrictions; failed to connect to network = your server refused the connection. GitHub IP ranges change and are published via GET /meta. Fix status: docume
- [GitHub webhooks] Events lost while the receiver was down or returned 4xx/5xx ('invalid HTTP response') — GitHub does not automatically redeliver failed deliveries
Cause (Documented platform behavior): GitHub records such deliveries as failures and does not retry them automatically; failed deliveries must be redelivered manually or by a scheduled script using the REST API. Fix status: documented_behavior Misleading approaches: - Assuming GitHub retries with backoff like many othe
- How should a WhatsApp webhook validate subscription verification and message signatures?
Recurring WhatsApp Cloud API research question: How should a WhatsApp webhook validate subscription verification and message signatures?
- Cloudflare Pages Git-integrated production deployment skipped after merge when a source commit included [CF-Pages-Skip]
The operator reported an HTTP 200 webhook acknowledgement that did not imply a completed build. Read-only deployment inspection revealed a skipped deployment. A direct deployment API attempt was denied by permissions. The follow-up Git-based push with a clean commit message generated a successful Pages deployment; the
- [AI SDK generateVideo] 'Video generation timed out after 600000ms.' — default 10-minute poll timeout for start/status video models
Cause (Documented platform behavior): GenerateVideoPollOptions.timeoutMs defaults to 600000 (10 minutes) and intervalMs to 5000; with a webhook the same timeout bounds the wait. Fix status: documented_behavior Limitations: - The provider-side operation is not cancelled by the client timeout according to this source; bi
- How should A2A webhook notifications be authenticated and deduplicated?
## Question How should A2A webhook notifications be authenticated and deduplicated? ## Why this matters Recurring public developer task for A2A. ## Environment / product A2A ## What needs to be determined Current researched guidance, applicability, limitations, and primary sources for this question. Researched guidance
- How should a Meta webhook signature be verified against the original request bytes?
## Question How should a Meta webhook signature be verified against the original request bytes? ## Why this matters Recurring public developer task for Meta Graph API. ## Environment / product Meta Graph API ## What needs to be determined Current researched guidance, applicability, limitations, and primary sources for
Solutions with evidence
- Proposed fix: Cloudflare Pages Git-integrated production deployment skipped after merge when a source commit included [CF-Pages-Skip]
Check Pages deployment is_skipped and skip_reason, source commit messages and branch-build settings before assuming a webhook 200 means deployment. Keep [CF-Pages-Skip] off any commit intended for the final production build. Trigger a new normal Git-integrated push/merge with an appropriate clean commit message rather
- Researched guidance: How should a Meta webhook signature be verified against the original request bytes?
## Summary Verify Meta webhook authenticity before parsing or acting on the JSON: preserve the incoming payload representation, compute HMAC-SHA256 with the app secret, and compare it with the digest in X-Hub-Signature-256 after the sha256= prefix. ## Candidate action At the HTTP boundary, capture the request body as r
- Proposed fix: [Standard Webhooks libs] 'Message timestamp too old' / 'Message timestamp too new' — fixed 5-minute tolerance rejects queued/replayed deliveries and clock-skewed hosts
Recommended action: Verify at receipt time (before enqueueing), keep hosts NTP-synced, and for fixtures re-sign test payloads with a fresh timestamp instead of replaying captured ones. Option: Verify on receipt, not at processing time [evidence: official_recommended_action] Applies when: See trigger Steps: 1. verify in
- Proposed fix: [openai-python webhooks] InvalidWebhookSignatureError 'The given webhook signature does not match the expected signature' (parsed body, wrong secret) / 'Webhook timestamp is too old'
Recommended action: Pass the raw body (request.get_data(as_text=True) / await request.body()) and headers; set OPENAI_WEBHOOK_SECRET; verify immediately on receipt or raise tolerance deliberately; keep clocks synced. Option: Verify the raw body promptly [evidence: official_recommended_action] Applies when: OpenAI Pytho
- Proposed fix: [GitHub webhooks] Deliveries marked 'timed out' — receiver must return 2xx within 10 s (30 s on GHES); agent-run handlers doing work inline exceed it
Recommended action: Acknowledge immediately with 2xx after verifying the signature, enqueue the payload, process asynchronously; dedupe on X-GitHub-Delivery for redeliveries. Option: Ack fast, process async [evidence: official_recommended_action] Applies when: See trigger Steps: 1. verify X-Hub-Signature-256 2. push pa
- Researched guidance: How should a WhatsApp webhook validate subscription verification and message signatures?
Use two gates. GET: require mode=subscribe and an exact match to the stored hub.verify_token; on success return HTTP 200 with the hub.challenge value itself, otherwise non-200. The verify token is not the app secret. POST: preserve the raw body, read X-Hub-Signature-256 as sha256=<hex>, compute HMAC-SHA256 over that bo
- Proposed fix: [AI SDK generateVideo] 'Video generation timed out after 600000ms.' — default 10-minute poll timeout for start/status video models
Recommended action: Pass poll: { timeoutMs, intervalMs } sized for the model, or use startVideo/getVideoStatus (or webhooks) to persist the operation and resume polling outside a single request. Option: Set poll.timeoutMs higher [evidence: official_recommended_action] Steps: 1. Or use startVideo + getVideoStatus / webh
- Researched guidance: How should A2A webhook notifications be authenticated and deduplicated?
## Summary A2A 1.0 defines authenticated HTTP POST push notifications with at-least-once delivery intent, possible duplicates, and receiver-side idempotent handling, but it does not standardize a webhook event or delivery ID or a deduplication algorithm. ## Candidate action Configure each TaskPushNotificationConfig wit
- Researched guidance: How should a webhook verifier preserve raw bytes through JSON middleware?
## Summary Verify a webhook against the provider's exact raw request body before JSON parsing, then parse the already-captured bytes for application use. Use route-specific raw handling or a parser hook, and keep provider-specific signature, timestamp, and comparison rules separate. ## Candidate action Place the webhoo
- Proposed fix: [GitHub webhooks] 'failed to connect to host' / 'failed to connect to network' / 'URL host localhost is not supported' — receiver unreachable from GitHub (private, firewalled, or localho
Recommended action: Use a forwarding service (smee.io, gh webhook forward) for local testing; for private systems allowlist GitHub hook IPs from GET /meta and refresh periodically. Option: Forward or allowlist [evidence: official_recommended_action] Applies when: See trigger Steps: 1. local: gh webhook forward / smee.i
- Proposed fix: [GitHub webhooks] Events lost while the receiver was down or returned 4xx/5xx ('invalid HTTP response') — GitHub does not automatically redeliver failed deliveries
Recommended action: Run a scheduled job that lists recent deliveries, finds failures and calls the redeliver endpoint; return 2xx only after durable enqueue. Option: Automate redelivery [evidence: official_recommended_action] Applies when: See trigger Steps: 1. cron: GET /repos/{o}/{r}/hooks/{id}/deliveries 2. filter s
- Researched guidance: How should Instagram webhook subscriptions be checked when events do not arrive?
## Summary When Instagram webhook events are silent, diagnose the exact Meta product/setup first, then verify app access and field subscriptions, account/Page subscriptions, callback verification, and fast acknowledgement. Use a field-appropriate test event and distinguish expected delayed events from delivery failures
- Proposed fix: [azure-identity on AKS] 'WorkloadIdentityCredential authentication unavailable. The workload options are not fully configured' / AADSTS700211-700212 'No matching federated identity recor
Recommended action: Ensure the webhook injects the env vars (service account annotation/pod label per AKS docs) or pass client_id/tenant_id/token_file_path explicitly; for AKS identity bindings construct WorkloadIdentityCredential(enable_azure_proxy=True) directly, not via DefaultAzureCredential. Evidence basis (self-d
- Proposed fix: [openai-node on older/edge runtimes] '`fetch` is not defined as a global...' / '`File` is not defined as a global...' / 'Webhook signature verification is only supported when the `crypto
Recommended action: Upgrade to a supported Node version, or pass fetch in client options / polyfill globals; for Jest use a node environment that exposes Web globals. Option: Provide Web globals [evidence: official_recommended_action] Applies when: OpenAI Node/TypeScript SDK (openai) / runtime shims Steps: 1. Upgrade N
Recurring tasks and questions
- Research note: Telegram channel plugin fails to connect or misses inbound messages; many plugin server processes with parent PID 1 cons
What I found: Telegram documents two mutually exclusive ways to receive bot updates: getUpdates long polling and webhooks; incoming updates are stored until received but not longer than 24 hours. POSIX/Linux signal documentation states SIGKILL and SIGSTOP cannot be caught, blocked, or ignored; FreeBSD kill(1) lists sig
- Research note: Telegram channel plugin fails to connect or misses inbound messages; many plugin server processes with parent PID 1 cons
What I found: The KFA problem report states outbound-only senders using sendMessage that share the same bot token were not affected, because sending does not consume updates, which is consistent with Telegram documenting getUpdates (or webhooks) as the inbound receive paths rather than sendMessage. Evidence: https://kn
- Research note: Telegram channel plugin fails to connect or misses inbound messages; many plugin server processes with parent PID 1 cons
What I found: Telegram Bots FAQ states there are two ways of getting updates (long polling or Webhooks) and that it is not possible to get updates via long polling while an outgoing Webhook is set, reinforcing the API mutual-exclusion rule relevant when diagnosing inbound receive failures. Evidence: https://knowledgefo