bigbigbigwaterbucket opened a new issue, #1084: URL: https://github.com/apache/incubator-seata-go/issues/1084
### ✅ Verification Checklist - [x] 🔍 I have searched the [existing issues](https://github.com/apache/incubator-seata-go/issues) and confirmed this is not a duplicate - [x] 🛠️ I am willing to try to fix this bug myself. ### 🚀 Go Version 1.24.10 ### 📦 Seata-go Version master(2.1.0) ### 💾 Operating System 🪟 Windows ### 📝 Bug Description In TCC fence log cleanup, pushCleanChannel falls back to logCache when logQueue is full: ``` select { case handler.logQueue <- fli: // todo add batch delete from log cache. default: handler.logCache.PushBack(fli) } ``` However, there is currently no logic to flush cached entries from logCache back into logQueue later. traversalCleanChannel only consumes logQueue, so identities stored in logCache may never be deleted. This may leave expired fence logs undeleted for a long time (or indefinitely under sustained queue pressure), and can also cause unbounded cache growth. ### 🔄 Steps to Reproduce 1. Initialize fence clean channel with a small queue or produce enough cleanup events quickly. 2. Trigger many calls to pushCleanChannel(...) (e.g., repeated duplicate key cases in PrepareFence, or many expired identities). 3. Ensure queue becomes full so some identities go into logCache. 4. Observe that traversalCleanChannel drains only from logQueue; cached identities remain in logCache and are not batch deleted. ### ✅ Expected Behavior When queue pressure drops, entries in logCache should be flushed back to logQueue and eventually batch deleted, so all intended (xid, branch_id) cleanup identities are processed. ### ❌ Actual Behavior Entries moved to logCache are not flushed and may never enter deletion flow, causing missed cleanup and possible memory growth. ### 💡 Possible Solution - Add a cache-drain mechanism that periodically moves entries from logCache back to logQueue when capacity is available, with a fallback to batch deletion if the queue remains full. - Protect logCache with a mutex to ensure thread-safe access under concurrent push and drain operations. - Introduce a fallback strategy to batch delete entries directly from the database when backpressure persists, preventing memory buildup. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
