We're working on a feature that simplifies my_chat_member into a group of events:

• bot.myStatus("joined", handler) will trigger when the bot is added to a group
• bot.myStatus("left", handler) will trigger when the bot leaves a group by itself (leaveChat)
• bot.myStatus("blocked", handler) will trigger when a user blocks the bot in private chat

and so on. All possible events:

• joined
• left
• banned
• restricted
• promoted
• demoted
• blocked
• unblocked

You can also listen for multiple events at once, like:

bot.myStatus(["blocked", "left", "banned"],	async ctx => {
	console.log(ctx.status.change); // the matched status change
	await removeChatIdFromDb(ctx.chat.id);
});

However, a problem arises when one my_chat_member update can cause two changes at once. For example, restricting a bot will also demote it from admin. In that case, you'll get the event you're looking for first. For example:

bot.myStatus('restricted', handler);
bot.myStatus('demoted', handler);

This will cause restricted to fire, but not demoted.

One idea I have here is when multiple events are expected on the same handler, fire all that apply for each update:

bot.myStatus(['restricted', 'demoted'], handler);

Here we can fire all that apply, so even when the bot is (which was previously promoted) restricted without demoting, handler will be called for both demoted and restricted events (even though the underlying update is only one).

Also consider the order here. Even though restricted is first in the array, the demoted event is fired first. If user intends on performing some actions based on these events, having a normalised order is useful.

Take for instance:

bot.myStatus(['promoted', 'joined'], ctx => {
	switch (ctx.status.change) {
		case 'joined': {
			ctx.chatSession.status = "member";
			return ctx.reply("Hello group!");
		}
		case 'promoted': {
			ctx.chatSession.status = "admin";
			return ctx.reply("Yay, good to be admin!");
		}
	}
});

In this case, if promoted was fired first, then joined, the resulting state of chatSession will be inconsistent. So we must have a normalised order of firing. This could also be accomplished (without us firing multiple events per update) in userland, using next():

bot.myStatus('joined', (ctx, next) => {
	// ...
	return next();
});

bot.myStatus('promoted', ctx => {
	// ...
	return next();
});

This pattern works without us calling the handler once per event, but puts the onus on the user to write events in the correct order.

Do you agree that all matching events on a myStatus handler must be fired per update?

👍🏻 Upvote for yes (fire an ordered list of all matching events)
👎🏻 Downvote for no (just fire once and let userland handle it)
💭 Reply in thread for other responses