DSV score corruption on nullable shadow source

[simontiffert]

I have a PlanningList project with task scheduling where sub-tasks are assigned to resources and every task can have multiple predecessors.
@ShadowSources({"resource", "previous.endDateTime", "predecessors[].endDateTime"})

• resource: containing the planning list of sub-tasks
• previous: PreviousElementShadowVariable in the planning list
• predecessors: a list of sub-tasks which needs to be finished before the sub-task can start

I have an additional dependency in the sub-task to another linked sub-task, which is nullable. I first tried solving it with inheritance as it is only for specific types of sub-tasks, but realized that re-defining the ShadowSources annotations violates rule 4.

The following annotation is causing a score corruption with TRACKED_FULL_ASSERT even if the variable unused (which is of type sub-task) is always null (in 1.23.0 + 1.24.0):
@ShadowSources({"resource", "previous.endDateTime", "predecessors[].endDateTime", "unused.endDateTime"})
And yes, it is called differently in the code, but I added a new variable to make sure it is not assigned and I can reproduce the issue.

I don't have a reproducer yet which I can provide, but if it is needed I can build one.

I tried solving it traditionally with the custom VariableListener as well, but is it possible to define a ShadowVariable for the list of predecessor sub-task objects?

[triceo]

Thanks for reporting this, Simon!
For an issue like this, I'd like to ask you to provide the reproducer.

[simontiffert]

@triceo See https://github.com/simontiffert/planning-list-with-dsv

[triceo]

Thank you!

[Christopher-Chianelli]

This is a duplicate of #1696 ; no variable/score corruption on main.

[triceo]

@simontiffert If you want to confirm with your own code, main branch should work for you. If you're still seeing issues, feel free to reopen.

[simontiffert]

I can confirm that it is working on the main branch.

In general DSV really simplifies working with PlanningList/chained approach, but on complex dependencies it is still easy to run into issues when the list of ShadowSources is not right.

Example - when looking at the documentation about DSV there is a Job entity which seems to be part of a PlanningList. If the first element is assigned to a resource there no previous element available. So the start time depends on resource changes as well which then needs to be part of the ShadowSources. When implementing it is essential to understand each incoming change. But when done the right way it really simplifies the complex looping logic of the custom variable listener which was there in before. Combined with loop detection it helps building this solutions.

Maybe add the option for a logging (trace statement) what triggered the method call as the source of the change is not visible and debugging complicated as the methods are called quite often.

[triceo]

I agree that "getting the sources right" is a major pain point with this API. We see that consistently with everyone who's tried the API so far and told us about it.