Telegram Trigger Node setWebhook drop_pending_updates=true?

Questions
1

Hi everyone,

I’ve noticed some behavior with the Telegram Trigger node in n8n (v1.91.3) and wanted to clarify if this is expected or possibly a bug.

When I deactivate a workflow that uses the Telegram Trigger, and then send messages to the bot during this inactive period, Telegram stores those messages. After I reactivate the workflow, the trigger node processes all of those previously sent messages at once. The getWebhookInfo call also shows a growing pending_update_count.

However, I don’t remember this being the case in previous versions — I believe earlier, the trigger only handled new messages after activation, not old ones sent during downtime.

So my questions are:

  1. Has this behavior changed recently in v1.91.3, or am I remembering it wrong?
  2. Is this the expected default behavior, or could this be considered a bug?
  3. If it’s expected — is there a way to force the Telegram Trigger to reset pending_update_count on activation, so it only handles messages that arrive after the workflow is reactivated?

Basically, I want the workflow to ignore any messages sent while it was deactivated.

Any insight or workaround would be greatly appreciated — thanks!

Information on your n8n setup

  • n8n version: 1.91.3
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
  • Operating system: Ubuntu 24.04
2

Hi @innoswarz

I don’t think there were any related changes on n8n’s side. If you want to clear the pending updates on Telegram’s side you can indeed use the drop_pending_updates parameter in the setWebhook or deleteWebhook endpoints.

drop_pending_updates: Pass True to drop all pending updates

docs: Telegram Bot API

If you reactivate the workflow after, all pending updates should be gone.

3

Hi @elsmr
Thanks for pointing that out!

If the setWebhook and deleteWebhook endpoints are the backbone of the Telegram Trigger node, it would be great to add an option to pass the optional parameter drop_pending_updates in the additional fields.

image
image483×660 36.9 KB

4

Nice idea :slight_smile:

5

@elsmr Yes, just to confirm — if I want to make drop_pending_updates: true work automatically when (re)activating a Telegram Trigger, I would need to create a custom Telegram Trigger node based on your existing one here:

And then in the create() method, I would simply need to modify the request body like this:

const body = {
	url: webhookUrl,
	allowed_updates: allowedUpdates,
	secret_token,
	drop_pending_updates: true,
};

Is that the right approach?
Or is there a better way to inject this parameter without forking the node?

Thanks in advance!

6

Yes, there’s a workaround…

You can skip using the Telegram Trigger node and instead use a Webhook node

However, you’ll need to manually set the webhook URL using the setWebhook endpoint, and also clear the existing webhook using deleteWebhook when stopping it.

This approach allows you to include the drop_pending_updates parameter when calling setWebhook via an HTTP request.

Here are the relevant endpoint you’ll need:

I tested it on my end and it’s actually working. However, I’m not sure about the implications if the intended use case is something more advanced…

7

Thank you. Yeah, I think I will add that HttpRequest (DeleteWebhook) node to the workflows and just push it before reactivating them when I needed. Not the most elegant solution, but it will do for now :wink: