forked from sass/tipibot
3b35f82d80
A follow-up reentrancy sweep of the five remaining money-moving views found one more instance of the same bug class. The other four (quests, prestige, fish, shop) verified clean - their underlying do_* functions are idempotent. RequestView / FundModal (commands/economy_support_commands.py): - on_submit read self._view.remaining, then awaited do_give, then decremented remaining. Because discord.py dispatches each modal submit as its own task and do_give is a plain non-idempotent transfer, a funder could open two modals and submit both before the first resolved: both read the same pre-decrement remaining, both passed the range check, and both transferred `amount` - over-funding the request (remaining goes negative) and moving up to the funder's whole balance. - Fix: reserve the amount synchronously (decrement remaining BEFORE the do_give await, with no await in between - atomic under asyncio), and roll the reservation back if the transfer fails. The second concurrent submit now sees the reduced remaining and is rejected. Added a cheap _fund guard (remaining<=0 / is_finished) so a click on a funded request doesn't open a dead modal. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>