For example, this is wrong:

@PlanningEntity
public class MyEntity1 extends BaseClass {
    String code;
    BaseClass entity1Value;

    public MyEntity1() {

    }

    public MyEntity1(String code) {
        this.code = code;
    }

    @PlanningVariable(valueRangeProviderRefs = {"entity1Range", "entity2Range", "valueRange"},
                      graphType= PlanningVariableGraphType.CHAINED)
    public BaseClass getEntity1Value() {
        return entity1Value;
    }

    public void setEntity1Value(BaseClass entity1Value) {
        this.entity1Value = entity1Value;
    }
}

@PlanningEntity
public class MyEntity2 extends BaseClass {
    // same contents as MyEntity1
}

MyEntity1.entity1value's value range refs must not contain the entity2range. Even though the model is "valid" type-wise (it compiles) it would result in invalid chains with loops and forks (multiple entities having the same value).

The documentation is clear on this:

A planning variable that is chained either:

• Directly points to a problem fact (or planning entity), which is called an anchor.
• Points to another planning entity with the same planning variable, which recursively points to an anchor.

Currently, this fails at runtime during solver.solve(). We should check the value ranges and fail fast during solverFactory.buildSolver().

I'm currently not sure how solver behaves during LS. My reproducer is too simple and doesn't have any constraints so the solver "solves" forever. But the solution after CH is definitely wrong (loops and forks).