-
Notifications
You must be signed in to change notification settings - Fork 73
Remove delete logic from mixed_db_client.go #383
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
base: master
Are you sure you want to change the base?
Conversation
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
This is a disruptive feature reverting. Let's explore a proper bugfix. |
@qiluo-msft We should remove this code from mixed_db_client.go as this is a path only used by community and has a clear race condition. MS ADO for proper bug fix. 32962839 |
What is "a path only used by community" |
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 removes the legacy delete-field logic from mixed_db_client.go
, simplifying message construction and preventing the outdated “delete” marker from being added or processed.
- Removed injection of a
"delete"
key into the MSI map indbSingleTableKeySubscribe
- Deleted the corresponding removal and handling of the
"delete"
field in thesendMsiData
helper
Comments suppressed due to low confidence (1)
sonic_data_client/mixed_db_client.go:1882
- After removing the delete-field logic, add or update unit tests to verify that MSI messages no longer include a "delete" key and that downstream behavior remains correct.
newMsi["delete"] = "null_value"
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.
LGTM
Why I did it
Race condition fixed in #375 in db_client.go. Same logic was copied which introduced issue in #139 was copied in #271. Removing it.
#139 introduced a race condition where one goroutine can read the values in msidata, while another goroutine can write to the same msidata map when constructing data to send. This causes a panic and causes process to crash.
How I did it
Removed logic of adding delete filed to map and deleting it introduced in #139, coped in #271.
How to verify it
Which release branch to backport (provide reason below if selected)
Description for the changelog
Link to config_db schema for YANG module changes
A picture of a cute animal (not mandatory but encouraged)