Trying Declarative Shadow Variable but got an UndoMove corruption

[kentbill]

Hi, teams,

I tried the DSV feature with a quite simple program but got an UndoMove Corruption. I have uploaded the code to the GitHub repository(https://github.com/kentbill/dsv-testing.git). This is a scenario that simulates assigning tasks to a production line. There are two constraints in the program, first, to ensure the correct task is assigned to the appropriate production line, and the other one is to punish the entity in an infinite loop. When I run the program, the following exception message appears, any idea about it? thanks in advance!

01:06:17.983 [main        ] TRACE     Model annotations parsed for solution JobScheduling:
01:06:17.986 [main        ] TRACE         Entity Job:
01:06:17.986 [main        ] TRACE             Shadow variable endTime (reflection)
01:06:17.986 [main        ] TRACE             Shadow variable looped (reflection)
01:06:17.986 [main        ] TRACE             Shadow variable nextJob (reflection)
01:06:17.986 [main        ] TRACE             Shadow variable previousJob (reflection)
01:06:17.986 [main        ] TRACE             Shadow variable productionLine (reflection)
01:06:17.986 [main        ] TRACE             Shadow variable startTime (reflection)
01:06:17.986 [main        ] TRACE         Entity ProductionLine:
01:06:17.986 [main        ] TRACE             Genuine variable jobList (reflection)
01:06:18.185 [main        ] DEBUG Using SLF4J as the default logging framework
01:06:18.248 [main        ] DEBUG Constraint weights for solution (1):
  Constraint (com.easyplan.domain/Unavailable production line) weight set to (-1hard/0medium/0soft).
  Constraint (com.easyplan.domain/Job has looped shadow variables.) weight set to (0hard/-1medium/0soft).
01:06:18.331 [main        ] INFO  Solving started: time spent (119), best score (0hard/0medium/0soft), environment mode (TRACKED_FULL_ASSERT), move thread count (NONE), random (JDK with seed 0).
01:06:18.332 [main        ] INFO  Problem scale: entity count (3), variable count (3), approximate value count (3), approximate problem scale (60).
01:06:18.360 [main        ] TRACE         Move index (0), score (0hard/0medium/0soft), move (JobO1 {null -> Line1[0]}).
01:06:18.362 [main        ] TRACE         Move index (1), score (0hard/0medium/0soft), move (JobO1 {null -> Line2[0]}).
01:06:18.364 [main        ] TRACE         Move index (2), score (0hard/0medium/0soft), move (JobO1 {null -> Line3[0]}).
01:06:18.366 [main        ] DEBUG     CH step (0), time spent (154), score (0hard/0medium/0soft), selected move count (3), picked move (JobO1 {null -> Line1[0]}).
01:06:18.370 [main        ] TRACE         Move index (0), score (0hard/0medium/0soft), move (JobO2 {null -> Line1[0]}).
01:06:18.372 [main        ] TRACE         Move index (1), score (0hard/0medium/0soft), move (JobO2 {null -> Line2[0]}).
01:06:18.375 [main        ] TRACE         Move index (2), score (0hard/0medium/0soft), move (JobO2 {null -> Line3[0]}).
01:06:18.378 [main        ] TRACE         Move index (3), score (0hard/0medium/0soft), move (JobO2 {null -> Line1[1]}).
01:06:18.381 [main        ] DEBUG     CH step (1), time spent (169), score (0hard/0medium/0soft), selected move count (4), picked move (JobO2 {null -> Line1[0]}).
01:06:18.390 [main        ] TRACE         Corruption detected. Diagnosing...
Exception in thread "main" ai.timefold.solver.core.impl.solver.exception.UndoScoreCorruptionException: UndoMove corruption (-2medium):
   the beforeMoveScore (-1init/0hard/0medium/0soft) is not the undoScore (-1init/0hard/-2medium/0soft),
   which is the uncorruptedScore (-1init/0hard/-2medium/0soft) of the workingSolution.

Corruption diagnosis:
Variables that are different between before and undo:
  - Actual value (true) of variable looped on Job entity (JobO2) differs from expected (false)
  - Actual value (true) of variable looped on Job entity (JobO3) differs from expected (false)
  - Actual value (true) of variable looped on Job entity (JobO1) differs from expected (false)

Missing variable listener events for actual move:
  - Entity (JobO2) is missing a afterVariableChanged call for variable (looped).
  - Entity (JobO3) is missing a afterVariableChanged call for variable (looped).
  - Entity (JobO1) is missing a afterVariableChanged call for variable (looped).



1) Enable EnvironmentMode TRACKED_FULL_ASSERT (if you haven't already)
   to fail-faster in case of a score corruption or variable listener corruption.
   Let the solver run until it reaches the same point in its lifecycle (Phase index (0), step index (2), move index (0).),
   even though it may take a very long time.
   If the solver throws an exception before reaching that point,
   there may be yet another problem that needs to be fixed.

2) If you use custom moves, check the Move.createUndoMove(...) method of the custom move class (LegacyMoveAdapter).
   The move (JobO3 {null -> Line1[0]}) might have a corrupted undoMove (Undo(JobO3 {null -> Line1[0]})).

3) If you use custom VariableListeners,
   check them for shadow variables that are used by score constraints
   that could cause the scoreDifference (-2medium).
	at ai.timefold.solver.core.impl.score.director.AbstractScoreDirector.assertExpectedUndoMoveScore(AbstractScoreDirector.java:777)
	at ai.timefold.solver.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.doMove(ConstructionHeuristicDecider.java:161)
	at ai.timefold.solver.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.decideNextStep(ConstructionHeuristicDecider.java:112)
	at ai.timefold.solver.core.impl.constructionheuristic.DefaultConstructionHeuristicPhase.solve(DefaultConstructionHeuristicPhase.java:75)
	at ai.timefold.solver.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:79)
	at ai.timefold.solver.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:194)
	at com.easyplan.Main.main(Main.java:64)

Process finished with exit code 1

[triceo]

Hello @kentbill, and thank you for your time!

This could be a bug - the feature is brand new, it will take a while to get it out of preview.
Unfortunately, we are a bit shorthanded at the moment due to PTOs, and we'll likely only be able to look into your issue in ~2 weeks' time when things settle down again.

We do take it seriously though - if we can confirm that this is a bug in the solver, we will fix it.

[kentbill]

Thank you very much for your response. @triceo This is a fantastic feature, and I'm excited to see it in action. I plan to try it out as soon as possible and hope to contribute to its development. Additionally, I would love to see it applied in as many scenarios as possible. I am sharing the challenges I encounter so that your team is aware of them.
Enjoy your vacation!


[Christopher-Chianelli]

Confirmed it a bug; fix in #1616