Aias00 opened a new issue, #6558: URL: https://github.com/apache/shenyu/issues/6558
## Description `doRetry` performs two non-atomic steps: `registerRepository.accept(key)` (persist; on success the data is now in admin), then `registerRepository.remove(key)` (drop the holder). A `persist*` call that fails *between* those two lines calls `addToFail(key)`, finds the still-present (pre-`remove`) entry, and returns early — so no retry task is scheduled for the new failure. `doRetry` then calls `remove(key)`, wiping the holder. The new failure now has neither a holder nor a timer task. ## Location ``` shenyu-register-client-api/.../retry/FailureRegistryTask.java:54-58 shenyu-register-client-api/.../FailbackRegistryRepository.java:175-184, 200-222 ``` ## Impact Lost registration of a legitimately-failing re-publish, under a narrow concurrency window. Compounds the failback-exhaustion issue. ## Suggested fix Make the retry-success and re-add paths atomic, e.g. `concurrentHashMap.compute(key, ...)`, or have `doRetry` re-check after `remove` whether a re-add is needed. ## Related existing issue(s) None _Identified during the 2026-08-02 audit; full list in [`docs/issue-candidates-2026-08-02.md`](docs/issue-candidates-2026-08-02.md)._ -- 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]
