feat(lock acquisition): introduce new error type and retry policy for lock acquisition

[danielchalef]

🚀 This PR description was created by Ellipsis for commit f76c55a.

Summary:

This PR introduces a new error type for lock acquisition failures, includes the failsafe-go package for retry policies, and updates memorystore.go and userstore.go to handle lock acquisition with a retry policy.

Key points:

• Added AdvisoryLockError in /pkg/models/errors.go
• Included failsafe-go package in go.mod and go.sum
• Added tryAcquireAdvisoryLock function in /pkg/store/postgres/memorystore.go
• Updated userstore.go to use failsafe.Get with a retry policy for lock acquisition

---

Generated with ❤️ by ellipsis.dev

[ellipsis-dev]

👍 Looks good to me!

• Reviewed the entire pull request up to f76c55a
• Looked at 172 lines of code in 5 files
• Took 42 seconds to review

More info

• Skipped 0 files when reviewing.
• Skipped posting 1 additional comments because they didn't meet confidence threshold of 50%.

1. /pkg/store/postgres/userstore.go:106:

• Assessed confidence : 0%
• Comment:
  The use of the 'failsafe-go' library for retrying the lock acquisition seems appropriate. The retry policy is set to handle 'models.ErrLockAcquisitionFailed' errors, with a delay of 200 milliseconds and a maximum of 3 retries. This should help in situations where the lock cannot be immediately acquired. The type of the returned value from the 'failsafe.Get' function is also correctly checked.
• Reasoning:
  The PR introduces a new library 'failsafe-go' for retrying the lock acquisition. The library is used in the 'Update' function of the 'UserStoreDAO' struct. The retry policy is set to handle 'models.ErrLockAcquisitionFailed' errors, with a delay of 200 milliseconds and a maximum of 3 retries. This seems to be a reasonable approach to handle situations where the lock cannot be immediately acquired. The code also correctly checks the type of the returned value from the 'failsafe.Get' function. The rest of the changes in the PR seem to be related to the introduction of this retry mechanism and do not introduce any new logic or modify existing one significantly. Therefore, I don't see any clear violations of best practices, logical bugs, performance bugs, or security bugs.

Workflow ID: wflow_SmN5iGiWhoA3jLmM

---

Not what you expected? You can customize the content of the reviews using rules. Learn more here.