Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: add concurrency protection to AssignmentCache (FF-4172) #53

Merged
merged 4 commits into from
Mar 25, 2025

Conversation

leoromanovsky
Copy link
Member

@leoromanovsky leoromanovsky commented Mar 24, 2025

Observation

Customer report of crash #52

Description

Dictionary access in Swift is not thread-safe; the implementation of AssignmentCache has no protection against concurrent access.

  • Adds DispatchQueue to guard access to the class
  • Multiple consumers can check the cache status
  • Only one thread can write at a time

Test plan

Wrote a test first to reproduce the issue

Screenshot 2025-03-24 at 1 57 04 PM

✔️ Implementation is passing the test

Rollout plan

This PR is opened against main branch and we need to back port this change to the 3.x branch and make a new release against it.

@leoromanovsky leoromanovsky marked this pull request as ready for review March 24, 2025 21:00
@@ -13,6 +13,7 @@ public struct AssignmentCacheKey {
}

public class InMemoryAssignmentCache: AssignmentCache {
private let queue = DispatchQueue(label: "com.eppo.assignmentcache", attributes: .concurrent)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor: have you considered using a Mutex instead? Given our sync blocks are very short, I would expect it to be a better fit here

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did give this a read - https://swiftrocks.com/thread-safety-in-swift

Does seem like an NSLock is the fastest but I value my understanding of this API and feel comfortable with it working, but would be open to re-implementing the usage here now that we have a test that demonstrates the bug.

@andrebocchini-reverb
Copy link

Thanks for the quick turnaround @leoromanovsky

@leoromanovsky leoromanovsky merged commit 3c939c7 into main Mar 25, 2025
1 check passed
@leoromanovsky leoromanovsky deleted the lr/ff-4172/crash branch March 25, 2025 17:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants