fix lock service ut

[iamlinjunhong]

User description

What type of PR is this?

• API-change
• BUG
• Improvement
• Documentation
• Feature
• Test and CI
• Code Refactoring

Which issue(s) this PR fixes:

issue #15757

What this PR does / why we need it:

fix lock service ut

---

PR Type

Tests

---

Description

• Changed timeout duration from seconds to milliseconds in TestLockSuccWithKeepBindTimeout and TestReLockSuccWithKeepBindTimeout to improve test precision.
• Replaced time.Sleep calls with loops checking conditions in TestReLockSuccWithReStartCN to avoid arbitrary delays and improve test reliability.
• Added additional assertions to ensure proper unlocking in TestReLockSuccWithReStartCN.

---

Changes walkthrough 📝

	Relevant files
Tests	service_test.go Improve lock service tests with precise timing and conditions pkg/lockservice/service_test.go Changed timeout duration from seconds to milliseconds in multiple tests. Replaced sleep calls with loops checking conditions in tests. Added additional assertions to ensure proper unlocking. +18/-22

---

💡 PR-Agent usage:
Comment /help on the PR to get a list of all available PR-Agent tools and their descriptions

[codiumai-pr-agent-pro]

PR Review 🔍

⏱️ Estimated effort to review [1-5]	2, because the changes are focused on improving test reliability and precision in a single file with a moderate amount of changes. The logic is straightforward, involving timing adjustments and replacing arbitrary sleep calls with condition checks.
🧪 Relevant tests	Yes
⚡ Possible issues	Possible Bug: The loop in TestReLockSuccWithReStartCN might lead to an infinite loop if the condition l1.isStatus(pb.Status_ServiceCanRestart) never becomes true. Consider adding a timeout mechanism or a maximum iteration count to prevent this.
🔒 Security concerns	No

[codiumai-pr-agent-pro]

PR Code Suggestions ✨

Category	Suggestion	Score
Best practice	Use t.Fatal instead of panic to fail the test gracefully Instead of using a panic statement, consider returning an error or using t.Fatal to fail the test gracefully. pkg/lockservice/service_test.go [1635] -panic("timeout bug") +t.Fatal("timeout bug") Suggestion importance[1-10]: 8 Why: Replacing panic with t.Fatal in test code is a significant improvement as it allows the test framework to handle failures more gracefully and provide more informative test failure messages.	8
Possible issue	Increase the timeout duration to reduce the risk of test flakiness Consider increasing the timeout duration from time.Millisecond to a slightly higher value to avoid potential flakiness in tests due to very short timeouts. pkg/lockservice/service_test.go [1350] -time.Millisecond, +time.Millisecond * 10, Suggestion importance[1-10]: 7 Why: The suggestion to increase the timeout from time.Millisecond to time.Millisecond * 10 is valid as it addresses potential flakiness in tests due to very short timeouts. This is a practical improvement for stability in test environments.	7
	Add a maximum number of iterations to prevent the loop from running indefinitely Add a check to ensure that the loop does not run indefinitely by setting a maximum number of iterations. pkg/lockservice/service_test.go [1629-1638] -for { +maxRetries := 100 +for i := 0; i < maxRetries; i++ { if l1.isStatus(pb.Status_ServiceCanRestart) { break } select { case <-ctx.Done(): - panic("timeout bug") + t.Fatal("timeout bug") default: + time.Sleep(time.Millisecond * 10) } } Suggestion importance[1-10]: 7 Why: Introducing a maximum number of iterations for the loop is a good practice to prevent potential infinite loops, enhancing the robustness of the test code. This suggestion also integrates well with the previous suggestion of using t.Fatal for error handling.	7
Performance	Add a small sleep duration inside the loop to avoid busy-waiting Add a small sleep duration inside the loop to avoid busy-waiting, which can consume unnecessary CPU resources. pkg/lockservice/service_test.go [1629-1638] for { if l1.isStatus(pb.Status_ServiceCanRestart) { break } select { case <-ctx.Done(): panic("timeout bug") default: + time.Sleep(time.Millisecond * 10) } } Suggestion importance[1-10]: 6 Why: Adding a sleep duration inside the loop can help reduce CPU usage due to busy-waiting. This is a good performance improvement, although not critical.	6