mirror of
https://github.com/MHSanaei/3x-ui.git
synced 2026-09-27 12:16:41 +08:00
n0ctal
d86a3def85
updateInboundClientIps wrote the [LIMIT_IP] lines that drive the jail while the scan's transaction was still open, and marked the addresses in bannedSeen at the same time. A commit failure after that point rolls the database back but takes nothing back from the log: fail2ban proceeds to ban addresses the panel never recorded, and the in-memory bannedSeen entry makes the next scan skip them, so the rollback is never repaired. Selection stays inside the transaction. processObserved now collects one pendingBan per enforced client and publishes after the commit succeeds, disconnecting only the clients whose lines actually reached the log. The Xray disconnects already ran after the commit for the same reason. Recording moved with the write rather than with the decision: selectAdvancedSinceLastBan no longer mutates anything, and recordBannedSeen runs once a line is on disk. It also runs for clients with nothing to ban, because that is the pass that forgets addresses a client no longer exceeds its limit with - pruning used to be a side effect of the filter, and skipping it left a stale entry that suppressed the next legitimate ban. The log file is opened once per scan instead of once per client, the write error is checked instead of discarded, and Close is reported. updateInboundClientIps no longer reports shouldCleanLog, because the only thing that set it was the ban branch that moved out; processObserved sets it when a publication actually happens. disAllowedIps went with the write it served. Tests: a transaction failed at COMMIT through a deferred foreign key leaves no line and no bannedSeen entry; a publication that cannot open the log leaves the address retryable; a client returning under its limit has its entry forgotten, so going over again is banned a second time; a committed over-limit scan publishes and reports; and writeBanLines surfaces a write error rather than swallowing it.