-
Notifications
You must be signed in to change notification settings - Fork 56
Fix concurrency issue of Component Registery of Azure Session #442
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
Conversation
Add the test cases for component registeration
2b81798 to
10ae7e0
Compare
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR addresses a concurrency issue in the component registration for AzureSession, ensuring that component initialization and event handler updates occur atomically during concurrent operations.
- Refactored component registration logic to use AddOrUpdate to improve thread-safety.
- Updated event handler registration and unregistration for handling listener components.
- Added extensive tests to validate different component registration and unregistration scenarios.
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/Authentication.Abstractions/AzureSession.cs | Updated RegisterComponent method to atomically update components and correctly manage event subscriptions under concurrency |
| src/Authentication.Abstractions.Test/AzureSessionTest.cs | Added tests covering parallel registration, unregistration, and event handler invocation scenarios |
What to fix
RegisterComponent, the operation that checks key existance_componentRegistry.TryGetValue(key, out var existed)and the operation that updates the value of the key_componentRegistry[key] = componentare not atomic. The result is the when you want to register the components with the same key in different threads in no-overwrite mode, the component is actually overwritten. What you can see is that with the unfixed codes, the result of the test caseTestComponentRegistrationSameComponentNoOverwrittenis unpredictable.