Inbound telegram: turns and corrections from the chat #187

2026-08-06T18:59:05+02:00

claude commented

2026-08-06 18:59:05 +02:00

Closes Vikunja #637.

Acceptance criteria and quality gate are in TASK.md on this branch.
Review the review, not the diff — leave comments and the agent will apply them via task start 637.

Closes Vikunja #637. Acceptance criteria and quality gate are in `TASK.md` on this branch. Review the review, not the diff — leave comments and the agent will apply them via `task start 637`.

claude added 8 commits 2026-08-06 18:59:05 +02:00

the correction gesture, as two taps in a chat (V-637) 42c7b8b927

Config gains an intake flag, off by default, and sendMessageReq gains the
inline keyboard the intake half hangs under a reply. The gesture itself is
the web's, ported: one button says the turn was wrong, and it opens the
seven intents rather than writing the negative straight away, because the
target is worth much more and he must still be able to decline naming one.

Button data comes off the wire, so parseCallback refuses an id it cannot
parse and a target that is not one of the seven. A label nothing can score
is worse than no label.

the bot API calls the inbound half makes (V-637) 45231ba69e

getUpdates, sendMessage, answerCallbackQuery and editMessageReplyMarkup,
plus the inbound shapes cut to what the poller reads. Every error goes
through the sink's redaction: the token is in the URL path because telegram
accepts it nowhere else, and net/http prints that URL on a transport
failure.

Only ok=true is a success, the same rule the push half already applies. A
relay that is up but cannot reach api.telegram.org answers 200 with an HTML
page of its own, and reading that as a batch of updates would be silent.

A chat id arrives as a number for a user and a string for a channel, so it
is held as json.Number and never converted.

the poller reads one chat and answers in it (V-637) d42372e996

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.

a fake bot API to test the poller against (V-637) 38be702188

An httptest server that hands out one batch of updates per getUpdates call
and records everything else, plus a recorder for what the poller asked the
daemon to do.

tests for the inbound telegram poller (V-637) 0a5211b038

The cases that matter: the turn runs with the chat as its dialogue id, the
reply carries the gesture, a turn nothing persisted carries no buttons, a
stranger gets no answer at all, the first tap writes nothing, and a write
that failed says so on the button instead of going quiet.

wiring the poller into both boot paths (V-637) c61b0b3968

It reaches the daemon through ipc.CoreAPI and nothing else, so a telegram
turn takes the path POST /api/chat already takes: Chat returns the reply and
the trace id it collected off the context (V-630), and CorrectTurn writes
the label. Nothing in internal/delivery learns what a handler is.

Wired on the unlocked start and on the passkey unlock, like the mail intake,
so telegram behaves the same either way. A sink that will not build is
logged rather than fatal here, because wireDispatcher already failed the
boot on the same config.

gofmt the act target guard (V-634) b3936348f5

Landed unformatted, so make test failed on fmt-check for everyone after.

telegram is no longer outbound only (V-637) 400653810e

The correction gesture now reaches all three surfaces, and CLAUDE.md said
only /chat had it. Doc 23 carries the decisions: long-poll rather than a
webhook, the backlog dropped on start, one accepted sender, and the two-tap
keyboard.

kami added 1 commit 2026-08-06 19:01:18 +02:00

the intake allowlist has to be a numeric chat id (V-637) 06c1cf247e

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.

claude merged commit ff70637a0d into master

2026-08-06 19:02:00 +02:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: kami/Maven#187