mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-10-24 12:42:49 +00:00
rcourtman
df41170313
Fixes #2540. A Telegram webhook passed **Test** while every real alert was rejected with `Bad Request: message text is empty`. **Cause.** The two paths built their headers differently: - The Test path always overlaid the service template's headers (`Content-Type: application/json`). - Real deliveries sent the stored header copy that the UI seeded when the webhook was created. An edit can leave that copy blank, masked or replaced. For example, the edit form shows the stored value as `***REDACTED***`, and clearing it saves an empty `Content-Type`. Telegram's HTTP reader parses body arguments only for JSON, form-urlencoded or multipart content types, and `sendMessage` checks `text` before `chat_id`. So a JSON body without a JSON Content-Type produces exactly that error. **Fix.** When a built-in service renders its own body (no custom template), the template's static headers describe that body: - `prepareWebhookDeliveryContext` applies them on every real firing and recovery, replacing stored values under any spelling of the header name. Unrelated stored headers stay. - The Test path uses the same `withWebhookTemplateHeaders` helper, so a passing Test predicts real delivery. - Custom templates and generic webhooks keep their stored headers. ntfy recoveries still build their own plain-text request. **Tests** (`internal/notifications/webhook_template_headers_test.go`): - A real queued Telegram alert, with blank, masked, replaced, lowercase and duplicate stored Content-Type values, now sends JSON with `text`. Before the fix it sent `""`, `***REDACTED***` or `text/plain`. - For every built-in service, the Test, grouped and resolved requests carry identical template headers and keep unrelated stored headers. - A custom template keeps its stored Content-Type. `go test ./internal/notifications` and `./internal/api/alerting` pass.