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
Fix broken downtime comment sync #10000
base: master
Are you sure you want to change the base?
Conversation
Sync all objects in priority descending order, otherwise downtimes, comments etc. might be synced before their respective checkables, which would result in comments/downtimes being ignored by the other endpoint since it doesn't yet know about their checkables. Since the runtime config updates event doesn't trigger a reload on the remote endpoint, theses objects won't be synced again til the next reload.
// trigger a reload on the remote endpoint, these objects won't be synced again til the next reload. | ||
std::vector<Type::Ptr> types = Type::GetAllTypes(); | ||
std::sort(types.begin(), types.end(), [](const Type::Ptr& a, const Type::Ptr& b) { | ||
return a->GetActivationPriority() > b->GetActivationPriority(); |
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.
Better call Type#GetLoadDependencies().
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.
What is Type#GetLoadDependencies()
supposed to bring me here? It would be nice if you could explain in more detail why you think activation priority is not right instead of simply suggesting "better call Type#GetLoadDependencies()
".
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.
Activation priority is just about in which order objects start doing things. In contrast, Type#GetLoadDependencies() reflects the load_after T;
we discussed offline. It fetches the types which must be loaded before the given type.
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.
Theoretically we could even merge
instead.
Sync all objects in activation priority descending order, otherwise downtimes,
comments etc. might be synced before their respective checkables, which
would result in comments/downtimes being ignored by the other endpoint
since it doesn't yet know about their checkables. Since the runtime
config updates event doesn't trigger a reload on the remote endpoint,
theses objects won't be synced again til the next reload/reconnect.
After master2 reload:
closes #7786
closes #9873