Skip to content

T 173

uid: T-173 title: Receipt bot β€” note confirmation rides in the processing status message status: done area: telegram-receipts created: 2026-07-22 updated: 2026-07-22 owner: girafeev1 assignee: Records (Infrastructure) related: T-169, T-172

Goal (owner, 2026-07-22)

After the force-reply note (T-169), the bot sent TWO messages: a standalone πŸ“ Got it: <note> confirmation, then the processing ack that the Inngest worker live-edits with step status. The owner wants one message, not two β€” verbatim:

"Instead of showing the confirmation and then proceed to process the receipt image in a new message, just include the confirmation as a quick showing of status in the image process message instead of leaving it out as an individual message"

What shipped

  • Webhook (pages/api/telegram/receipt-webhook.ts):
  • handleNoteReply no longer sends the standalone πŸ“ Got it: message.
  • The single-subsidiary ack β€” the message that becomes the live status message β€” now opens with πŸ“ Got it: <i>note</i> and carries the filing line under it.
  • The multi-subsidiary picker header and the pickSub "Filing under…" edit carry the same note header, so every flow (force-reply note, caption-confirm, picker) shows the note exactly once, inside the message that then shows processing status.
  • Worker (lib/inngest/receipt-processor.ts): status edits replace the whole message text, so updateStatus now prefixes every frame (Downloading β†’ Reading β†’ Cleaning β†’ Cropping β†’ Sending) with the πŸ“ <i>note</i> header β€” the confirmation stays visible for the status message's whole life. The not-a-receipt/unparseable rejection and the retries-exhausted failure edit keep the header too: with several uploads in flight it's what tells the user WHICH photo the verdict is about. The status message is still deleted once the summary lands β€” no note is lost because the summary caption renders πŸ—’ Note: itself.
  • Why prefix every edit, not just the first frame: Telegram editMessageText replaces the whole text β€” a header only on the initial ack would be wiped by the first "Downloading…" edit within ~a second, which would fail the "confirmation" half of the ask.

Log

  • 2026-07-22 β€” created + done (Records Infrastructure; owner instruction quoted above, proposed and approved in the same message). βœ… Read AGENTS.md Β· checked the board by scope (T-169 owns the note prompt, T-172 the step split; neither covers the confirmation-message UX β€” no dup). Source: Records (Infrastructure) Β· https://claude.ai/code/session_018RDB37kCqfouHdygVXTAtD
  • SHAs: 270671a3 (code) + the docs commit carrying this record; merged to main via PR. Full unfiltered NODE_OPTIONS=--max-old-space-size=8192 npx tsc --noEmit clean pre-merge.
  • Deploy pending β€” merged, not deployed (deploys are owner-ordered). Owner runtime-verify (after the next deploy): upload a captionless receipt, reply with a note β†’ the reply is followed by ONE message that opens πŸ“ Got it: <note> and then walks the processing statuses with the note line pinned on top; no separate confirmation message appears.
  • Blast-radius: Telegram receipt UX only β€” message composition in the webhook ack/picker and the worker's status/rejection/failure edits. No schema, store, Inngest step-layout, or web-app changes. In-flight receipts at deploy time keep working (the note header simply appears on their next status edit).