-
Notifications
You must be signed in to change notification settings - Fork 6
fix: use local shadow document to update the last sync doc during a c… #215
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
…loud update request
|
Unit Tests Coverage Report
Minimum allowed coverage is Generated by 🐒 cobertura-action against 1b6dd49 |
|
Integration Tests Coverage Report
Minimum allowed coverage is Generated by 🐒 cobertura-action against 1b6dd49 |
|
It'd be great to get this fix merged and released, as the current behavior causes lots of issues :-/ |
| .orElseThrow(() -> new UnknownShadowException("Shadow not found in sync table")); | ||
|
|
||
| if (!isUpdateNecessary(shadowDocument, currentSyncInformation, context)) { | ||
| if (!isUpdateNecessary(currentLocalShadowDocument, currentSyncInformation, context)) { |
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.
| if (!isUpdateNecessary(currentLocalShadowDocument, currentSyncInformation, context)) { | |
| if (!isUpdateNecessary(localShadowDocument, currentSyncInformation, context)) { |
I think we can remove the DAO call to get the latest shadow. The currentSyncInformation will always lag the shadow document in the request (aka the localShadowDocument so this condition will always evaluate to the same regardless of which shadow document is used.
This will reduce the amount of state required for this function which should make it simpler to test.
5cc2eb1 to
d31424e
Compare
d31424e to
1b6dd49
Compare
#215) * fix: use local shadow document to update the last sync doc during a cloud update request * refactor: remove unnecessary DAO calls
…loud update request
Issue #, if available:
Description of changes:
In Shadow manager, there's a race condition where
CloudUpdateSyncRequestis created for shadow state X, but when executed, the shadow is at state Y. The sync info gets updated with state Y instead of the actual synced state X. This prevents subsequent requests to be skipped with "Cloud shadow already contains update payload". Restarting GG or shadow manager will not fix this issue.When
MergedFullShadowSyncRequestprocesses multipleCloudUpdateSyncRequests, the first request incorrectly updates sync info to the latest local version, causing subsequent requests to be skipped with "Cloud shadow already contains update payload". This occurs becauseCloudUpdateSyncRequest.isUpdateNecessary()updates the sync info to the current shadow version inupdateSyncInformationVersion()but thelastSyncedDocumentdoesn't reflect what was actually synced, creating inconsistency.Solution:
Modified
updateSyncInformationVersion()to use the shadow document state that was captured when the sync request was created, ensuring sync info accurately reflects the state that was actually processed, not the current shadow state.Why is this change necessary:
Fixes issues where local shadows are not synced to the cloud intermittently even when sync direction allows it.
How was this change tested:
Any additional information or context required to review the change:
Checklist:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.