mirror of
https://github.com/tiennm99/tiennm99bot.git
synced 2026-10-11 03:13:46 +00:00
tiennm99
23d3f67ca3
A /delpack confirmation outlived the record that authorised it. The under-lock re-check listed the states it would refuse - a pending record still naming this set - and fell through on the two that mattered: no record at all, and a record that had moved on to a different pack. Reachable with ordinary commands and no attacker: run /delpack without pressing, let the pack disappear from Telegram's side so a self-heal frees the name, let another user claim it, then press. DeleteStickerSet is keyed by set name, which Telegram authorises for every set this bot created, so the press destroys whoever holds the name at that moment. Invert the guard: delete only when a confirmed record still names this exact set. A check phrased as "which states do I refuse" cannot fail closed against a state nobody enumerated. Dropping a pack record now also clears any outstanding confirmation, so a dead prompt stops existing rather than merely being refused on use. This also stops the reservation leaking when a confirmed delete lands on a record that has moved on, since that case no longer reaches Telegram. Alongside: - Resuming an interrupted /newpack discarded a retyped title and reported success quoting the old one. - TestNewPack_DifferentSlugReplacesDeadIntent was named for releasing a dead name and never asserted it. - lockUser's comment justified the lock with cron and stats-hook contention that does not exist: the map is state-local and this module registers neither. The lock stays for the read-modify-write pattern; a wrong reason for a right guard misleads the next reader.