Replying to another bot's message and running /alias answered with the
list of kinds that can be saved, which blames the format of a message
the bot was never shown — it may well have been a photo. Telegram strips
the content of another bot's message, and the sender is not always marked
as a bot: an anonymous or service-posted message arrives equally empty,
so the existing bot check missed it.
Judge on whether any content arrived instead. A reply with no content
field at all, and a command that arrives with no reply attached, now both
say what happened and end with the one action that works: forward the
message into the chat and reply to your own copy. A reply that did arrive
with content of a refused kind — a poll, a location — still gets the list
of supported kinds.
One contentFields table backs both the check and the alias_capture debug
line, so the log line always explains the refusal the caller was given.
The capture failures worth debugging are all about what Telegram did not
deliver: a reply stripped of its content, a caption where text was
expected, or a kind that falls through the switch. None of that is
visible from the user-facing refusal, which only says "unsupported".
One alias_capture line per /alias reports field names, lengths and
counts — never message text, so aliased messages cannot travel with the
logs.
tiennm99