A book-club member submits “Recommend Book A” to a Telegram bot, then edits the original message to say “Recommend Book B.” Should the bot change the recommendation, add another entry, or leave the confirmed record alone? Telegram does not choose that business rule for you.
Before asking AI to build the bot, separate a new version of a chat message from permission to change a business record. A book-club recommendation list makes the distinction concrete and testable.
An edit is not a fresh submission
The aiogram Update reference distinguishes new messages, edited messages, and edited channel posts. It also warns that changes to fields the bot does not use or cannot see may trigger an edit update. Receiving an edit does not, by itself, prove that a book title changed.
The grammY filter guide likewise separates new-message handling from edits; its edit shortcut covers edited messages and channel posts. Do not assume a new-text handler also receives edits, or that one framework's filter syntax is a universal platform interface.
These references explain event handling, not whether your application should synchronize a record. The rules below are design recommendations, not mandatory Telegram behavior.
Decide whether messages are input or a live data source
A conservative recommendation workflow could use three rules:
- Before confirmation, the recommendation is a draft. Editing its source message updates the linked draft's title or note and produces a refreshed preview.
- After confirmation, the recommendation is an independent record. Editing the chat text does not overwrite it; the bot explains how to request a change explicitly.
- Once a recommendation is being displayed or voted on, changing its title could change what other people believe they are choosing. Require administrator review where appropriate instead of silently replacing the subject.
This works for submissions that become commitments. A channel-mirroring bot may instead need continuous synchronization. If so, define the fields, time window, and locked content that synchronization must respect. Do not alternate unpredictably between treating messages as submitted forms and treating them as a live database.
Link the source to a record; do not replay the command
Give each recommendation its own business ID and retain the source chat and message identifiers. The source identifies the input; the business ID identifies what people confirm or change later. Matching by book title alone is not a safe substitute.
When an edit arrives, evaluate it in this order:
- Does the source belong to a known recommendation in this book club? If not, do not create a recommendation from the edited command. Ask for a new submission or explicit review.
- Is the record a draft, confirmed, or locked? Apply that state's modification policy first.
- Did a field the workflow actually uses change? Compare the stored title and note rather than announcing every event as a content change.
- If modification is allowed, update the linked record and report the result. Do not run the “add recommendation” action again.
Editing /recommend Book A into /recommend Book B must not consume another submission slot. Editing it into a different command must not switch activities or initiate another business action.
An imported bot may have no source mapping for an older message. A received version may also be impossible to order confidently against the stored content. In either case, pause the overwrite and request confirmation. An edit event is not a reliable shortcut for reconstructing unknown history.
Acceptance cases for the edit policy
You can specify observable outcomes before choosing implementation details:
- Change Book A to Book B while still drafting: there is one draft, its preview shows Book B, and confirmation applies to that refreshed preview.
- Edit the source after confirmation: the record remains Book A and the bot explains the change-request route instead of claiming synchronization succeeded.
- Change message information unused by the workflow: the recommendation stays unchanged and no misleading change alert appears.
- Edit an old message with no known association: no new entry appears and no similarly named record is overwritten.
- Rewrite the source as a submission to another activity: the existing record does not move between activities.
- Send an ordinary new submission: the new-message flow still works after edit handling is added.
These cases test event routing, identity, state, and feedback separately. Deletion is a different problem: the existence of edit updates does not establish that the bot can detect every ordinary chat-message deletion and clean up its records.
A requirements prompt for BotFatherV2
You can give BotFatherV2 a request like this:
Build a book-club recommendation list. New submissions are drafts and become public only after confirmation. Synchronize title and note edits only when the source belongs to a known draft; ignore unrelated field changes. Confirmed or locked records must not change when the chat text is edited, and need an explicit modification route. Edits must not create entries, consume another slot, or switch activities. Ask for confirmation when the source or version order is unknown. First explain whether the current Telegram Serverless SDK can receive and distinguish the required edits, then implement and test each case above. State any unsupported entry point clearly.
Public product information checked on October 18, 2026 describes conversational bot creation and modification, importing existing Telegram Serverless bots, publishing versions, and rolling code back while retaining current business data. The AI development documentation sets validation boundaries: support for a particular event in the current SDK still needs its own check. Documentation for aiogram or grammY cannot establish a BotFatherV2 capability.
The documented fixed SDK does not support arbitrary npm modules or Node/Bun runtime APIs, and the first release does not add bot runtime features that depend on paid AI. This prompt therefore does not ask the platform to install those frameworks or run an autonomous AI agent. BotFatherV2 is independently operated and is not affiliated with Telegram's official BotFather.
Sources and scope
- aiogram project: Update — aiogram 3.31.0 documentation, English reference; no publication date displayed. Checked October 18, 2026.
- grammY project: Filter Queries and bot.on(), English guide; no publication date displayed. Checked October 18, 2026.
The business policy, requirements prompt, and acceptance cases are original editorial guidance. The framework references verify event and filtering distinctions, not an integration with BotFatherV2.