mirror of
https://github.com/tiennm99/tiennm99bot.git
synced 2026-10-11 03:13:46 +00:00
tiennm99
1810c1ee47
Two ordinary /newpack commands could take over a stranger's pack. The first probe returns an inconclusive error, which correctly keeps the reservation so the user can retry - but that turned a fresh claim into a resumed one and defeated the guard that made adoption conditional. resolveStaleIntent had a second adopt path that never consulted the guard at all. Both are reproduced by tests added here. This is the fourth failure of the same mechanism, and it is structural. Adoption must prove "this set is mine to finish" from local state, and local state is what a restart on the in-memory backend erases while the packs at Telegram survive. With the proof gone, a genuine interrupted attempt and a stranger naming a public share link are indistinguishable. Remove adoption entirely. /newpack refuses any name a set already occupies, and leaves no intent or reservation behind when it does. A pending record is not evidence of ownership either: anyone can make one naming any set, and DeleteStickerSet is keyed by set name, which Telegram authorises for every set this bot created. /delpack therefore clears a pending record locally and contacts Telegram only for a confirmed one. The cost is that a crash between creating a set and recording it strands that set. That is documented rather than mitigated - every mitigation available is the mechanism that just failed. Also drop a test whose name claimed to pin the resumed-reservation distinction but bailed past the code that implements it, rename a delpack test after the guard that actually stops a foreign presser, and pin releaseSlug's ownership check and detached read - the latter needed a context-honouring store, since the in-memory one ignores cancellation and made the first version of that test vacuous.