RSDK-9233, RSDK-8904 - only call updateWeakDependents once per reconfiguration level #4585

cheukt · 2024-11-25T21:26:37Z

Bug:

If a resource with weak dependencies (data manager) depend on a resource (sensor), and the sensor reconfigures, the viam-server will get stuck in an infinite reconfigure loop. This is because in the process of getting dependencies for the data manager, we will run updateWeakDependents (because the sensor has updated but weak dependents have not), and in the process of running getDependencies inside updateWeakDependents we will continue to trip the check at r.lastWeakDependentsRound.Load() <= node.UpdatedAt(), meaning this will call updateWeakDependents in an infinite loop
an associated bug was if multiple resources were in the same level, there is a chance that updateWeakDependents will be called at the same time and reconfigure the same resources at the same time

Fix:

Only update weak dependents once per reconfiguration level
Only update weak dependents if something in the resource graph has updated (logical clock has to be greater than lastWeakDependentsRound
A secondary optimization was added so that we only updateWeakDependents if the resource actually depends on something with weak dependencies.

Since we can't guarantee that any resource depending on weak dependents will get "the most updated" weak dependent anyway, perhaps we should just guarantee that those weak dependents will be as updated as the last reconfiguration level

dgottlieb · 2024-11-26T17:19:27Z

Mostly looks good. I'd like to get more detail on the expected behavior written down somewhere. So if we have a robot config where:

sensor explicitly depends on datamanager
datamanger weakly depends on everything

For the following scenarios:

Robot first comes up
the sensor config changes
a third component config changes (triggering data manager reconfig)

What's the order of the following events:

Which resources have their Reconfigure called + when are they called
When the logical clock is read from
When the logical clock is bumped

cheukt · 2024-11-27T23:21:19Z

added tests and updated comments

benjirewis

Looking good, some initial comments.

robot/impl/local_robot.go

robot/impl/resource_manager.go

robot/impl/robot_reconfigure_weak_dependencies_test.go

Co-authored-by: Benjamin Rewis <[email protected]>

benjirewis

LGTM assuming tests pass; thanks!

robot/impl/robot_reconfigure_weak_dependencies_test.go

dgottlieb · 2024-12-04T14:14:33Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	// (that also has an explicit dependency on one of the components).
+	// The following scenario is expected:
+	// 1) The two bases will configure first in parallel (which will each bump the logical clock).
+	// 2) The completeConfig loop will check to see if there is a need to updateWeakDependents by


We run completeConfig at the end of each "level" of reconfigure? At the end of each resource?

I always assumed "complete" inferred the last step before localrobot.Reconfigure returns.

Looking more closely, I'm not sure what @cheukt means by "The completeConfig loop." completeConfig is, indeed, one of the final steps of Reconfigure/reconfigure for a local robot. completeConfig also runs every 5s if any resources are still in NodeStateConfiguring or NodeStateUnhealthy.

With @cheukt's changes, updateWeakDependents no longer runs as part of getDependencies. It now runs in the following situations:

Every 5s when any changes in remote resources or resources are still in NodeStateConfiguring / NodeStateUnhealthy

Right after initial construction

Upon orphaned resource removal

After completeConfig in reconfigure

Potentially at the end of each level in completeConfig
a. This one is new and only happens when "any resources in the level needs reconfiguration and depends on weak dependents, and the resource graph has updated since the last time weak dependents were updated"

I mentioned offline that I was worried one of these 5 updateWeakDependents calls might be unnecessary. Now, I can't convince myself that we can remove any of them 😆 . In any case, let's not worry about the other updateWeakDependents callsites in this PR.

This mostly makes sense to me, thanks! Maybe I asked this question in the wrong test. I think the case I've asked you to describe is when base1 strongly depends on weak1. And in this test was just have weak1 strongly and weakly depending on base1.

Potentially at the end of each level in completeConfig

That reads to me as:

First we reconfigure base1+base2

Then we reconfigure weak1

Which sounds fine because we want to update weak1 because things it depended on changed.

But then the sub-bullet says:

a. This one is new and only happens when "any resources in the level needs reconfiguration and depends on weak dependents, and the resource graph has updated since the last time weak dependents were updated"

Editorializing to make sure we're on the same page:

any resources in the level needs reconfiguration (e.g: base1) and depends on weak dependents (e.g: weak1), and the resource graph has updated since the last time weak dependents (e.g: base1) were updated

That to me reads as we're reconfiguring the weak dependents because something else depends on them. Normally we want to reconfigure "leaf nodes" first, then work our way up (or down?) to the things that depended on those leaf nodes. But my interpretation of this algorithm is that we're intentionally updating things in the opposite order that we normally do?

Potentially at the end of each level in completeConfig

is inaccurate based on the code - I'm pretty sure updateWeakDependents is being run in the beginning of the loop, and that is the intention because of the case Dan is describing

I'm pretty sure updateWeakDependents is being run in the beginning of the loop, and that is the intention because of the case Dan is describing

You're referencing this call to updateWeakDependents?

I'm not sure if it is linking correctly, but I think we have the same idea. https://github.com/viamrobotics/rdk/pull/4585/files#diff-77fd7ff51c1b7804c67c4df0a9a672ea0e3842b4a54bbd8ef81af82ac95c4f22R657

dgottlieb · 2024-12-04T14:17:18Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	// The following scenario is expected:
+	// 1) The two bases will configure first in parallel (which will each bump the logical clock).
+	// 2) The completeConfig loop will check to see if there is a need to updateWeakDependents by
+	//    checking the logical clock on also whether there are dependencies on weak dependents.


Does "dependencies on weak dependents" mean "explicit/"strong" dependencies on weak dependents"?

I interpreted this as "resources that have an API/model pair with weak dependencies." I believe @cheukt is using the words "weak dependents" to mean resources upon which other resources weakly depend.

Made a suggested change on your earlier in-line comment to potentially change the language here and elsewhere for %s:dependencies on weak dependents/has weak dependencies/g.

my comment is meant to convey what @dgottlieb is saying. I'm using "weak dependents" to mean "resources with weak dependencies" but can see why it's confusing. Can't really think of a better name though, but I also feel that "resources with dependencies that have weak dependencies" is also just as confusing. Open to other phrasing!

dgottlieb · 2024-12-04T14:18:43Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	// 1) The two bases will configure first in parallel (which will each bump the logical clock).
+	// 2) The completeConfig loop will check to see if there is a need to updateWeakDependents by
+	//    checking the logical clock on also whether there are dependencies on weak dependents.
+	//    The check will fail.


I think on -> and? ("checking the logical clock on")

Which conditions fail? I think the "last round" is still at 0 and the "clock" is at 2 now? So this would fail because we haven't initialized weak1 yet? ("There are no components with weak dependencies?")

I think on -> and?

Agree, it should be and.

Which conditions fail?

Failure (no update of weak dependents from @cheukt 's new updateWeakDependents call in completeConfig) occurs when the "last round" is GTE the clock value or when no resources have weak dependencies.

I think the "last round" is still at 0 and the "clock" is at 2 now?

Yep.

So this would fail because we haven't initialized weak1 yet? ("There are no components with weak dependencies?")

Yep.

So this would fail because we haven't initialized weak1 yet? ("There are no components with weak dependencies?")

No, this failed because there are no dependencies on weak dependents in level 2, e.g. nothing depends on weak1

dgottlieb · 2024-12-04T14:18:56Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	//    checking the logical clock on also whether there are dependencies on weak dependents.
+	//    The check will fail.
+	// 3) weak1 will configure.
+	// 4) At the end of reconfiguration, weak1 will reconfigure once.


Logical clock will be at 3 now? And last round is still 0?

Logical clock will be at 3 now?

4 now.

And last round is still 0?

Correct.

last round is 4 - adding a check and additional documentation to clarify

I'm definitely misunderstanding last round; will need some clarification on its value offline.

dgottlieb · 2024-12-04T16:09:50Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+
+	// Reconfigure base2
+	// The following scenario is expected:
+	// 1) The base2 will reconfigure (which will bump the logical clock).


I would bet it's 7 at this point. I'll stop answering these ones, but we definitely need assertions on the logical clock.

added the assertions

dgottlieb · 2024-12-04T16:13:19Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	test.That(t, weak1.reconfigCount, test.ShouldEqual, 2)
+
+	// Reconfigure base2
+	// The following scenario is expected:


What is the "last weak dependency round" here? And when does it get bumped?

added language around each scenario about the expected last weak dependency round

dgottlieb · 2024-12-04T16:15:56Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	test.That(t, weakCfg3.Ensure(false, logger), test.ShouldBeNil)
+	robot.Reconfigure(context.Background(), &weakCfg3)
+
+	res, err = robot.ResourceByName(weak1Name)


Same as above -- ideally changed to weakRes.

dgottlieb · 2024-12-04T16:17:02Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	test.That(t, err, test.ShouldBeNil)
+	test.That(t, weak1.reconfigCount, test.ShouldEqual, 3)
+
+	// check that getting dependencies for either resource does not increase reconfigCount


I'd recommend changing "getting dependencies" to "calling getDependencies". And "does not increase reconfigCount" to "does not change weak1.reconfigCount".

dgottlieb · 2024-12-04T16:18:52Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	lRobot := robot.(*localRobot)
+	node, ok := lRobot.manager.resources.Node(weak1Name)
+	test.That(t, ok, test.ShouldBeTrue)
+	lRobot.getDependencies(weak1Name, node)


The comment says "getting dependencies for either resource does not".

I was assuming that'd be "base1" and "base2". But instead we're checking "weak1" and "base1". I can't tell if those cases have specific logic we're trying to exercise? Or if "base2" is considered redundant? But I'm not sure why it would be. Given it's different from base1 in that it is not an explicit dependency for weak1.

the infinite loop issue happened because getDependencies ended up calling reconfig on weak1 which chained infinitely. this check is basically a check that getDependencies do not have side effects on the resource graph, and the tests here are already set up. Can move to a different test if that makes more sense

robot/impl/resource_manager.go

benjirewis · 2024-12-05T17:20:31Z

robot/impl/resource_manager.go

@@ -629,6 +629,41 @@ func (manager *resourceManager) completeConfig(
 	levels := manager.resources.ReverseTopologicalSortInLevels()
 	timeout := rutils.GetResourceConfigurationTimeout(manager.logger)
 	for _, resourceNames := range levels {
+		// if any resources in the level needs reconfiguration and depends on weak dependents,


Suggested change

// if any resources in the level needs reconfiguration and depends on weak dependents,

// if any resources in the level need reconfiguration and have weak dependencies,

The phrase "depend on weak dependents" is pretty confusing to me. Is my rephrasing there accurate with what you're meaning?

it's not accurate - what I mean is if any resource in the level need reconfiguration and depends on a resource that have weak dependencies. So if the resource depends on something that would be affected by updateWeakDependents.

I ended up using the same phrasing as the function name, but definitely can be confusing

Thanks for clarifying; I see now you're using GetAllParentsOf on resources in the level and then checking whether those parents (resources that depend on the original resource) has weak dependencies. Now I'm more confused on how we arrived on that being part of the requirement for updateWeakDependents; let's talk about in the meeting later.

robot/impl/resource_manager.go

robot/impl/local_robot.go

benjirewis · 2024-12-05T17:24:50Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	// (that also has an explicit dependency on one of the components).
+	// The following scenario is expected:
+	// 1) The two bases will configure first in parallel (which will each bump the logical clock).
+	// 2) The completeConfig loop will check to see if there is a need to updateWeakDependents by


I mentioned offline that I was worried one of these 5 updateWeakDependents calls might be unnecessary. Now, I can't convince myself that we can remove any of them 😆 . In any case, let's not worry about the other updateWeakDependents callsites in this PR.

benjirewis · 2024-12-05T17:37:41Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+
+	// Reconfigure base1
+	// The following scenario is expected:
+	// 1) The base1 will reconfigure (which will bump the logical clock).


benjirewis · 2024-12-05T17:38:32Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	// 1) The base1 will reconfigure (which will bump the logical clock).
+	// 2) The completeConfig loop will check to see if there is a need to updateWeakDependents by
+	//    checking the logical clock on also whether there are dependencies on weak dependents.
+	//    The check will fail.


I'm confused, too, @cheukt ; shouldn't the check pass? As @dgottlieb pointed out, it definitely looks like weak1 gets a second Reconfigure... Step (4) here therefore sounds incorrect.

benjirewis · 2024-12-05T17:40:48Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	// 2) The completeConfig loop will check to see if there is a need to updateWeakDependents by
+	//    checking the logical clock on also whether there are dependencies on weak dependents.
+	//    The check will fail.
+	// 3) weak1 will not reconfigure, as base1 was not newly built or error during reconfiguration.


I don't understand why (2) fails (if it does,) and I do not think the "newly built" or "reconfig error" pieces here have to do with it. Agree with @dgottlieb 's rewording, too: something like weak1 will not reconfigure, as base1 was neither newly built nor errored during reconfiguration.

benjirewis · 2024-12-05T17:44:48Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+				// We need the following `robot.Reconfigure` to call `Reconfigure` on this `base1`
+				// component. We change the `Attributes` field from the previous (nil) value to
+				// accomplish that.
+				Attributes: rutils.AttributeMap{"version": 1},


I think this would work, too, but I have no strong opinion on what you currently have vs. @dgottlieb 's suggestion.

benjirewis · 2024-12-05T17:45:35Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+
+	// Reconfigure base2
+	// The following scenario is expected:
+	// 1) The base2 will reconfigure (which will bump the logical clock).


I would bet it's 7 at this point. I'll stop answering these ones, but we definitely need assertions on the logical clock.

cheukt

I think I addressed everything, let me know if there are further qs

cheukt · 2024-12-06T21:34:56Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	weak1, err := resource.AsType[*someTypeWithWeakAndStrongDeps](res)
+	test.That(t, err, test.ShouldBeNil)
+	// Assert that the weak dependency was tracked.
+	test.That(t, weak1.resources, test.ShouldHaveLength, 2)


so this is a bug that the weak dependency system creates and I'm not looking to fix here. weak1 will be called a few times during reconfiguration. if reconfigure is called during the "regular" reconfiguration loop (the one with level), the reconfigure will only have the strong dependency passed in. during updateWeakDependents however, we will call it with both bases . Because we do make sure to call updateWeakDependents before we exit out of reconfiguration, the list of dependencies should be 2.

Edit: the paragraph above is wrong. We do grab both weak and strong dependencies and pass them in at the same time - we dedupe using a map of [resource.Name]{resource}

cheukt · 2024-12-06T21:44:23Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	// 1) The base1 will reconfigure (which will bump the logical clock).
+	// 2) The completeConfig loop will check to see if there is a need to updateWeakDependents by
+	//    checking the logical clock on also whether there are dependencies on weak dependents.
+	//    The check will fail.


adding additional words to explain, but basically these checks fail because there is nothing that depends on weak dependents (ex: weak1) in the next level

cheukt · 2024-12-06T21:50:02Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	// 2) The completeConfig loop will check to see if there is a need to updateWeakDependents by
+	//    checking the logical clock on also whether there are dependencies on weak dependents.
+	//    The check will fail.
+	// 3) weak1 will not reconfigure, as base1 was not newly built or error during reconfiguration.


cheukt · 2024-12-06T21:50:44Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	//    checking the logical clock on also whether there are dependencies on weak dependents.
+	//    The check will fail.
+	// 3) weak1 will not reconfigure, as base1 was not newly built or error during reconfiguration.
+	// 4) At the end of reconfiguration, weak1 will reconfigure once.


updateWeakDependents will reconfigure weak1. adding language to clarify

cheukt · 2024-12-06T21:52:05Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+
+	// Reconfigure base2
+	// The following scenario is expected:
+	// 1) The base2 will reconfigure (which will bump the logical clock).


added the assertions

cheukt · 2024-12-06T21:56:55Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	lRobot := robot.(*localRobot)
+	node, ok := lRobot.manager.resources.Node(weak1Name)
+	test.That(t, ok, test.ShouldBeTrue)
+	lRobot.getDependencies(weak1Name, node)


the infinite loop issue happened because getDependencies ended up calling reconfig on weak1 which chained infinitely. this check is basically a check that getDependencies do not have side effects on the resource graph, and the tests here are already set up. Can move to a different test if that makes more sense

cheukt · 2024-12-06T21:59:39Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	// 2) The completeConfig loop will check to see if there is a need to updateWeakDependents by
+	//    checking the logical clock and also whether there are dependencies on weak dependents.
+	//    The check will fail.
+	// 3) weak1 will not reconfigure, as base1 was not newly built or error during reconfiguration.


I did intend for the base1 bit there, since I wanted to give a reason as to why weak1 did not reconfigure. Can remove if it's confusing

cheukt · 2024-12-06T22:00:21Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	test.That(t, weak1.reconfigCount, test.ShouldEqual, 2)
+
+	// Reconfigure base2
+	// The following scenario is expected:


added language around each scenario about the expected last weak dependency round

cheukt · 2024-12-06T22:02:04Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+				// We need the following `robot.Reconfigure` to call `Reconfigure` on this `base1`
+				// component. We change the `Attributes` field from the previous (nil) value to
+				// accomplish that.
+				Attributes: rutils.AttributeMap{"version": 1},


cheukt · 2024-12-06T22:03:28Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	test.That(t, err, test.ShouldBeNil)
+	weak1, err = resource.AsType[*someTypeWithWeakAndStrongDeps](res)
+	test.That(t, err, test.ShouldBeNil)
+	test.That(t, weak1.reconfigCount, test.ShouldEqual, 2)


we run updateWeakDependents at the end of reconfiguration, which is why this has been bumped. let me know if the comments communicate the story better now.

benjirewis · 2024-12-09T19:17:37Z

Since this PR is pretty noisy already, I assume you two are alright with continuing to discuss the weak dependency system in person later this week?

dgottlieb · 2024-12-10T15:11:32Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	test.That(t, err, test.ShouldBeNil)
+	test.That(t, weak1.reconfigCount, test.ShouldEqual, 2)
+
+	test.That(t, lRobot.lastWeakDependentsRound.Load(), test.ShouldEqual, 5)


So reconfiguring base1 calls SwapResource and bumps the clock. But "weak reconfiguring" weak1 does not result in a SwapResource?

yep, we don't call SwapResource when "weak reconfiguring."

yep, we don't call SwapResource when "weak reconfiguring."

Why do we not call SwapResource when weak reconfiguring?

My understanding is that we don't want the logical clock to increase when weak reconfiguring.

cheukt

responded, @dgottlieb you said you had some changes ready so did not make further doc changes yet

cheukt · 2024-12-13T23:01:06Z

revamped documentation once more, hopefully things are a bit clearer now

benjirewis

What's the state of this PR now? The current comments LGTM and I answered my remaining question (I think.)

benjirewis · 2024-12-16T18:19:04Z

robot/impl/robot_reconfigure_weak_dependencies_test.go

+	test.That(t, err, test.ShouldBeNil)
+	test.That(t, weak1.reconfigCount, test.ShouldEqual, 2)
+
+	test.That(t, lRobot.lastWeakDependentsRound.Load(), test.ShouldEqual, 5)


My understanding is that we don't want the logical clock to increase when weak reconfiguring.

cheukt added 3 commits November 25, 2024 14:03

attempt

29794b4

some refactoring

7eb18af

clarification

e896926

viambot added the safe to test This pull request is marked safe to test from a trusted zone label Nov 25, 2024

add tests

d5fb8f3

cheukt requested a review from dgottlieb November 25, 2024 22:53

viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Nov 25, 2024

Lint

2f0d364

viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Nov 26, 2024

add comment

a21cd5f

viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Nov 27, 2024

some fixes

1e3f440

viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Nov 27, 2024

cheukt changed the title ~~RSDK-9233 - Fix infinite loop inside getDependencies()~~ RSDK-9233, RSDK-8904 - only call updateWeakDependents once per reconfiguration level Nov 27, 2024

cheukt requested a review from benjirewis November 27, 2024 23:23

cheukt mentioned this pull request Dec 2, 2024

RSDK-8904: Only update weak dependencies once per reconfigure. #4584

Closed

lint

240dff3

viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Dec 2, 2024

lint

e2e12e7

viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Dec 2, 2024

benjirewis reviewed Dec 2, 2024

View reviewed changes

Update robot/impl/local_robot.go

9d7c86e

Co-authored-by: Benjamin Rewis <[email protected]>

viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Dec 2, 2024

cheukt requested a review from benjirewis December 2, 2024 20:35

benjirewis approved these changes Dec 2, 2024

View reviewed changes

dgottlieb reviewed Dec 4, 2024

View reviewed changes

benjirewis reviewed Dec 5, 2024

View reviewed changes

pr feedback

3a4118d

viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Dec 6, 2024

cheukt commented Dec 6, 2024

View reviewed changes

dgottlieb reviewed Dec 10, 2024

View reviewed changes

Merge branch 'main' into fix-infinite-loop

4094d78

cheukt commented Dec 10, 2024

View reviewed changes

viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Dec 10, 2024

cheukt requested a review from dgottlieb December 10, 2024 17:54

Merge branch 'main' into fix-infinite-loop

71ec5d2

viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Dec 11, 2024

cheukt added 3 commits December 13, 2024 12:54

Merge branch 'main' into fix-infinite-loop

bd6f19f

update comments

9bd530a

more updates

5f6209e

viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Dec 13, 2024

benjirewis approved these changes Dec 16, 2024

View reviewed changes

dgottlieb approved these changes Dec 17, 2024

View reviewed changes

cheukt merged commit 9098976 into viamrobotics:main Dec 17, 2024
16 checks passed

cheukt deleted the fix-infinite-loop branch December 17, 2024 22:15

	// if any resources in the level needs reconfiguration and depends on weak dependents,
	// if any resources in the level need reconfiguration and have weak dependencies,

RSDK-9233, RSDK-8904 - only call updateWeakDependents once per reconfiguration level #4585

RSDK-9233, RSDK-8904 - only call updateWeakDependents once per reconfiguration level #4585

Conversation

cheukt commented Nov 25, 2024 • edited Loading

dgottlieb commented Nov 26, 2024 • edited Loading

cheukt commented Nov 27, 2024

benjirewis left a comment

Choose a reason for hiding this comment

benjirewis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cheukt Dec 6, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cheukt Dec 6, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cheukt Dec 6, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cheukt left a comment

Choose a reason for hiding this comment

cheukt Dec 6, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cheukt Dec 6, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

benjirewis commented Dec 9, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cheukt left a comment • edited Loading

Choose a reason for hiding this comment

cheukt commented Dec 13, 2024

benjirewis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cheukt commented Nov 25, 2024 •

edited

Loading

dgottlieb commented Nov 26, 2024 •

edited

Loading

cheukt Dec 6, 2024 •

edited

Loading

cheukt Dec 6, 2024 •

edited

Loading

cheukt Dec 6, 2024 •

edited

Loading

cheukt Dec 6, 2024 •

edited

Loading

cheukt Dec 6, 2024 •

edited

Loading

cheukt left a comment •

edited

Loading