The push half accepts an @channelusername and the intake half cannot: an
inbound update names its chat by number, so an @-name matches nothing. The
check lived in NewPoller, which wireTelegramIntake logs and returns from, so a
box configured that way booted clean with a dead intake half and a working push
half. Nothing looked broken from the chat.
ValidateIntakeChatID moves the rule where config validation can reach it, the
same shape validateNetScan uses. It is stricter than the old prefix test: any
non-digit is refused, not just a leading @. An empty token or chat id still
means telegram is not wired, because an unset ${TELEGRAM_*} expands to empty
and that must not fail a box with no bot.
deploy/mavend.json turns intake on. The chat id on this box is numeric.
The onCallback comment claimed every path answers the callback. The fromOwner
early return does not, and silence toward a stranger is correct, so the comment
was what was wrong.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two defects my own review found.
The push half accepts @channelusername as a destination. The intake half
cannot: an inbound update names its chat by numeric id, so that config would
read the chat, match nothing, and answer none of it. Refused at NewPoller,
which turns a dead reach into a line in the log.
And getUpdates returns at most 100 updates per call, so one call was not the
backlog. The skip loops, bounded at ten rounds rather than until empty, so
an instance that keeps handing back a full batch cannot spin.
Long-poll getUpdates rather than a webhook: the box takes no inbound
connections and reaches telegram through a relay, so the direction has to
stay outbound. A failed poll waits and retries, because the relay going
down is the normal cause and it comes back on its own.
The backlog is discarded on start. Telegram holds undelivered updates for
24 hours, so a daemon that was down overnight would otherwise answer every
question in order, and a reminder set from an eight-hour-old message lands
at the wrong time. Missing it is the safe direction.
ChatID is the only accepted sender and anything else is dropped without a
reply, because a reply confirms the bot exists and whose it is. Chat ids are
not guessable but they are not secret either, so that is the whole
authorisation and it is an allowlist of one.
claude