Skip to content

a reader's bug report goes to Telegram instead of a Slack channel (cherry-pick of #2956) - #2960

Closed
Flotapponnier wants to merge 1 commit into
mainfrom
cherry/telegram-main
Closed

Flotapponnier wants to merge 1 commit into
mainfrom
cherry/telegram-main

Conversation

@Flotapponnier

Copy link
Copy Markdown
Collaborator

a reader's bug report goes to Telegram instead of a Slack channel

/api/report posted to a Slack incoming webhook. A report is one person
saying a number on the page looks wrong, which is the most useful message
this site receives and the one most worth reading the same day. It now goes
to a Telegram bot that DMs whoever owns the chat id.

Telegram is tried first, Slack stays as the fallback it was, and with
neither configured the route still answers 503 and the form still says
reporting is not configured. So nothing breaks before the environment is
set, and the Slack webhook can be retired whenever you like rather than in
the same change.

Both variables are required together. A token with no destination would look
configured and send every report into a 502.

Three details that are the whole reason this is not a two-line patch:

HTML, not Markdown. Every value a reporter controls — the message, the
contact, the User-Agent — already goes through slackSafe, which escapes &, <
and >. That is exactly Telegram's HTML escape set, so the existing
sanitising carries over unchanged. Markdown would need a different set and
the two would drift apart the first time someone edited one.

The response body is never logged. Telegram puts the bot token in the
request URL rather than a header, and its error payload echoes the request,
so the Slack path's habit of logging the body would have printed the token
into the server log. Status code only.

4096 characters, Telegram's own ceiling, applied after assembly rather than
to the message alone: the bench line, the page URL and the three context
lines all count toward it.

.env.example documents both variables and, more usefully, how to find a chat
id at all: it is the destination, not the bot, and it only exists once
someone has written to the bot.

)

a reader's bug report goes to Telegram instead of a Slack channel

/api/report posted to a Slack incoming webhook. A report is one person
saying a number on the page looks wrong, which is the most useful message
this site receives and the one most worth reading the same day. It now goes
to a Telegram bot that DMs whoever owns the chat id.

Telegram is tried first, Slack stays as the fallback it was, and with
neither configured the route still answers 503 and the form still says
reporting is not configured. So nothing breaks before the environment is
set, and the Slack webhook can be retired whenever you like rather than in
the same change.

Both variables are required together. A token with no destination would look
configured and send every report into a 502.

Three details that are the whole reason this is not a two-line patch:

HTML, not Markdown. Every value a reporter controls — the message, the
contact, the User-Agent — already goes through slackSafe, which escapes &, <
and >. That is exactly Telegram's HTML escape set, so the existing
sanitising carries over unchanged. Markdown would need a different set and
the two would drift apart the first time someone edited one.

The response body is never logged. Telegram puts the bot token in the
request URL rather than a header, and its error payload echoes the request,
so the Slack path's habit of logging the body would have printed the token
into the server log. Status code only.

4096 characters, Telegram's own ceiling, applied after assembly rather than
to the message alone: the bench line, the page URL and the three context
lines all count toward it.

.env.example documents both variables and, more usefully, how to find a chat
id at all: it is the destination, not the bot, and it only exists once
someone has written to the bot.
@Flotapponnier

Copy link
Copy Markdown
Collaborator Author

Closing: already shipped. Cherry-pick to main of #2956, which reached main
through the release merge #3021 on 2026-10-18.

All 66 substantial lines this PR adds are already present in main.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant