-
Notifications
You must be signed in to change notification settings - Fork 46
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
chore: override state transitions into topic #1659
base: main
Are you sure you want to change the base?
Conversation
stateTopic.overrideValue(newState.ordinal()); | ||
statusCodeTopic.withValue(stateTransitionEvent.getStatusCode().name()); | ||
statusReasonTopic.withValue(stateTransitionEvent.getStatusReason()); |
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.
the statuses should be overridden too
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.
oh yeah, silly me
19cf9de
to
032644b
Compare
032644b
to
4f2da75
Compare
Unit Tests Coverage Report
Minimum allowed coverage is Generated by 🐒 cobertura-action against 4f2da75 |
Integration Tests Coverage Report
Minimum allowed coverage is Generated by 🐒 cobertura-action against 4f2da75 |
@@ -128,6 +128,10 @@ private Topic overrideValue(Object nv) { | |||
return withNewerValue(this.modtime, nv); | |||
} | |||
|
|||
private Topic overrideValue(Object nv, long proposedModTime) { |
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.
This doesn't make sense, it won't do anything different from with newer value.
The point of overriding is that the value provided here is going to be set no matter what the timestamp is on the node. This implementation won't do that, this is a straight up alias for with newer value.
Issue #, if available:
Description of changes:
Override changes to lifecycle state transition into the Nucleus config tree.
Why is this change necessary:
Today, we first compare the timestamps of the previously persisted lifecycle state and the incoming lifecycle state. If, due to clock skew, previously persisted state is in the future compared to the incoming state, the incoming state is rejected. This can cause an endless loop of timestamp comparisons between persisted and incoming state, blocking the main thread, bricking the device.
How was this change tested:
Any additional information or context required to review the change:
Documentation Checklist:
Compatibility Checklist:
any deprecated method or type.
Refer to Compatibility Guidelines for more information.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.