Now interrupt the response after the spreadsheet accepts the append. The worker sees a timeout. If it retries the entire job, the operator may receive two enquiries. If it assumes success, it may acknowledge a request whose write never completed. Neither conclusion follows from the timeout alone.

We built a small reference implementation to make that boundary inspectable. It uses synthetic enquiries and an offline demonstration; it is not a client incident report or a production reliability benchmark. The default run calls no external service and needs no credentials.

The submission is not the Telegram user

A chat identifier tells the bot where a conversation happens. It does not identify a single business request. One person can legitimately submit two enquiries. Using their chat ID as the deduplication key would suppress the second one.

Give each confirmed submission a stable reference and preserve its payload. A repeated confirmation should refer to the existing submission. A new enquiry should receive a new reference. If an existing reference arrives with different material fields, stop and inspect the conflict rather than silently treating the changed payload as a replay.

The reference keeps request type, summary and chat identity with the submission. An intake layer still needs to show the summary and obtain confirmation. The downloadable module starts after that boundary; it is not a complete conversation bot.

Persist the intention before attempting the write

A useful set of write states is:

pending → attempting → confirmed
                    ↘ uncertain → reconciliation or review

Persisting attempting before the external request lets a later worker recognise that an interrupted attempt may have crossed the boundary. It should not restart as if no write had been attempted.

The example serialises work inside one processor. That handles concurrent calls in that process. It is not a substitute for transactional storage and worker claims when several processes operate on the same queue. The included file adapter is a teaching convenience, not a crash-proof distributed transaction.

Append does not enforce your business identity

Google Sheets values.append finds a logical table in the supplied range and adds values after it. The application supplies its own submission reference as a column. The append method does not make that reference unique.

The reference uses RAW input for enquiry text and expects a fixed six-column layout. Both choices are explicit parts of the adapter contract. Renaming a tab or rearranging columns is a configuration change that needs a test, not an invisible spreadsheet housekeeping task.

API behaviour: https://developers.google.com/workspace/sheets/api/reference/rest/v4/spreadsheets.values/append

When an earlier append is uncertain, the processor looks for the submission reference and compares the stored request fields. Exactly one matching row can reconcile that write. Multiple rows, conflicting content or no matching row leave a review task.

An empty lookup immediately after a timeout is not treated as proof that it is safe to append again. That conservative choice can require an operator. It avoids turning incomplete evidence into an automatic second side effect.

Acknowledgement is a separate operation

Suppose the spreadsheet write is confirmed and only the Telegram response is lost. Repeating the spreadsheet append cannot fix the acknowledgement. The write already has its own result.

Keep confirmation state separately:

write: confirmed
acknowledgement: uncertain

On a successful sendMessage response, the Bot API returns a Message. Retain the returned identifier as evidence of API acceptance. It does not establish that the recipient read the message. After an unknown result, choose a deliberate recovery policy rather than treating another send as harmless.

API reference: https://core.telegram.org/bots/api#sendmessage

In the teaching reference, an uncertain acknowledgement goes to review and is not automatically repeated. A production product could choose a different tradeoff, but it should name that tradeoff and make the outcome visible to its operator.

Test the boundary, not just the success message

The offline demo submits one enquiry, replays it and then submits a different enquiry from the same synthetic chat. The result is two recorded rows and two acknowledgements. That is an observation from the demo, not an exactly-once claim about real external APIs.

The automated checks also interrupt the append after acceptance, restart the processor, supply conflicting row content, return multiple matching rows and lose an acknowledgement response. They check that the processor preserves the distinction between confirmed work and an unknown outcome.

Adapter tests use synthetic request/response data. We did not connect real Google or Telegram accounts for this exercise. A deployment still needs authenticated intake, a supported credential flow, production storage, quotas and bounded retries, monitoring, retention and a recovery owner.

The source and setup notes are linked from the WeMAIde Telegram/Sheets integration guide: https://wemaide.com/insights/telegram-bot-google-sheets-integration?utm_source=hashnode&utm_medium=referral&utm_campaign=telegram-sheets-reference

Keep the operator's question answerable

The useful question is not merely whether the workflow ran. It is which confirmed request was recorded, whether the external write is known to exist, whether its acknowledgement completed and which uncertainty still needs attention.

Separating those records makes a small integration easier to recover. It also keeps the implementation honest: local coordination, external acceptance and a person's confirmation are related events, not one transaction.

Disclosure: Prepared with AI assistance and reviewed against the accompanying reference code and its local tests. All demonstration enquiries are synthetic. No client results, production uptime or performance savings are claimed.