grafana/grafana#89393 telegram 2-step send to fix formatting errors

[danilgotvyansky]

Issue: Fixes grafana/grafana#89393

Description:

Here is how I tried to fix the issue with Grafana and Telegram communication being corrupted by Telegram failing to validate parsing syntaxes if the message is truncated

I am not a Go developer, but I've tried to show my idea:

• Format message after the truncation to get guaranteed delivery with none parse mode
• To achieve this, we send a message with none parse mode always and then edit it separately after successful delivery with HTML or Markdown* syntaxes.

I've verified that a new approach works for HTML, but it doesn't fully work for Markdown since Markdown is not currently working in the master branch version, either, and in Grafana Cloud, according to my tests.

Here is also some technical info for these changes:

More

1. Webhook Infrastructure Enhancement (http/client.go, http/webhook.go, receivers/webhook.go)

• SendWebhook method signature changed: Now returns (*receivers.WebhookResponse, error) instead of just error
• Added WebhookResponse struct: Captures StatusCode, Body, and Headers from HTTP responses
• Enhanced error handling: Maintains response data even when validation fails
• Purpose: Enables receivers to access HTTP response details for processing (critical for Telegram message ID extraction)

2. Telegram Message Editing Feature (receivers/telegram/v1/telegram.go)

• Added message ID tracking: lastMessageID field with thread-safe access via mutex
• Two-step sending process:
  1. Send message with parse_mode="" (None) to ensure delivery
  2. Edit message with configured parse_mode to apply formatting
• New methods:
  • EditMessage(): Edits existing messages using Telegram's editMessageText API
  • extractMessageID(): Parses Telegram API response to extract message ID
  • GetLastMessageID() / SetLastMessageID(): Thread-safe message ID management
• API endpoint support: Added editMessageText alongside existing sendMessage and sendPhoto

3. Test Updates (receivers/telegram/v1/telegram_test.go)

• Updated expectations: Tests now expect two webhook calls per message (send + edit)
• Parse mode handling: First call sends without formatting, second applies configured parse mode
• Response mocking: Added mock response bodies with message IDs for testing

4. All Receivers Updated (19 receiver implementations)

• Signature compatibility: All SendWebhook calls updated to handle new return signature
• Minimal impact: Most receivers just ignore the response with _ since they don't need it
• Maintained functionality: No behavioral changes, just API compatibility

[CLAassistant]

All committers have signed the CLA.

[fopina]

I like the idea: always send none and let edit be the one to fail silently!

I can’t really comment on the code though couldn’t the change be restricted to telegram webhook only? So it would send and edit in the “send” method?
Avoiding impact in every webhook due to function signature changes

[danilgotvyansky]

@fopina Yeah, I tried like that at first, but since the edit action requires response details, it would require either Telegram using an exclusive SendWebhook function or adding a response into an existing one, which requires all other receivers to expect a response and do nothing with it.

The second approach looked easier :)