By Bo
I use a Telegram operator workflow to review drafted replies before anything can reach a recipient. The useful part is not the button itself. It is the distinction between a proposed message, a human decision, and evidence that the message was actually sent.
One documented revision session made that distinction concrete. I replaced a batch of drafts with corrected wording. The operator approved the replacements, and the approved records reached the outbox. The delivery component was unavailable at that checkpoint. Approval had happened; delivery had not.
That is a normal queue state. Calling it “sent” would be a reporting defect.
Separate the records by responsibility
The recorded workflow uses newline-delimited JSON files between components. A drafts feed holds candidate replies. A revision feed carries operator corrections. An outbox holds approved work. An events feed records delivery outcomes and incoming replies.
This separation makes inspection straightforward. I can ask whether a draft exists without implying that it was approved, and inspect an approval without implying that the external platform accepted it.
Here is a deliberately simplified state sketch. It describes the responsibilities, not a complete implementation of the existing bot:
draft -> shown -> approved -> queued -> confirmed sent
\-> revision requested -> new draft
\-> rejected
old shown draft -> replaced
queued -> delivery uncertain -> reconciliation
The distinction between queued and confirmed sent must survive a worker restart. A friendly Telegram notification cannot substitute for a durable outcome record.
Approve a particular version
In the revision session, the bot assigned each replacement a new draft identifier. The old cards were closed before the new records were introduced. The bot's callback handler rejected actions on drafts whose stored status was no longer “shown.”
That server-side check matters because the operator may still have an old card visible on a phone. Editing a card improves the interface, but stored state determines whether its button can authorize anything.
The practical rule is simple: approval belongs to the version the person reviewed. If the wording changes, create a new version and require a new decision. Do not let a worker edit an already approved body while keeping the approval attached.
The same principle applies to recipients and destinations. A review screen should make clear where the exact approved text is intended to go.
Treat Telegram as the interface
The Telegram Bot API provides callback queries for button interactions. Its callback acknowledgement method clears the client's progress indicator. Acknowledging that interaction is separate from recording authorization or completing delivery.
For a new implementation, I would resolve a short callback reference against server-side state, check the actor's authorization, and verify that the referenced version is still actionable. I would also make the state transition and outbox insertion one recoverable operation.
These are implementation requirements I would verify explicitly. The historical session proves replacement-card handling; it does not establish transactional guarantees under simultaneous callbacks or process crashes.
Keep revisions visible
The operator needs a clear answer to “which text am I approving?” In the documented workflow, a replacement appears as another version, and a superseded card says that its text will not be sent.
A revision request is work too. After satisfying it, the drafting component must mark or otherwise reconcile that request. The session notes identified a request that was already satisfied but still present in the revision feed. Consuming it again could have created an unnecessary additional draft.
I prefer a visible pending revision to a silent rewrite. The former can be inspected; the latter makes it difficult to explain which wording crossed the approval boundary.
Handle delivery uncertainty honestly
A sender can fail before submission, after submission, or while waiting for confirmation. Those cases need different recovery decisions. An outbox row alone cannot tell them apart.
For a production sender, I would use a stable delivery reference, exclusive claiming, and durable result recording. After an ambiguous timeout, I would reconcile the destination's history before retrying. Where the destination has no idempotency support, I would preserve an explicit uncertain state for review rather than promise exactly-once delivery.
That is a proposed hardening pattern, not a claim that a JSONL file automatically implements it. Multiple writers also need locking or a transactional store. Append-only storage is useful for a timeline, but it does not resolve concurrency by itself.
Test the boundaries without sending
Useful local checks include pressing an obsolete card, approving the same version twice, revising after approval, and restarting a worker between queue insertion and outcome recording. A test sender should capture intended output locally, with external delivery disabled.
I would check the copy as well as the state machine. The revised drafts in the recorded session used first-person wording because the operator was speaking personally. A mechanically valid approval of misleading text is still a poor result.
My acceptance question is therefore specific: can I trace this exact message from reviewed version, to authorized decision, to independently observed delivery outcome? If the trace stops at the outbox, I report “approved and queued.” That small wording discipline keeps a convenient Telegram interface from becoming an unreliable account of what happened.
Top comments (0)