Stefan Schröder

You can easily add your own reason handler via [UnassignedJobReasonTracker](https://github.com/graphhopper/jsprit/blob/master/jsprit-core/src/main/java/com/graphhopper/jsprit/core/util/UnassignedJobReasonTracker.java) like this: ``` UnassignedJobReasonTracker reasonTracker = new UnassignedJobReasonTracker(); reasonTracker.put("SimpleNameOfYourConstraint",21,"could not be assigned due to your constraint"); ```

You are correct. This is unnecessary overhead. However, the current approach has been the least intrusive. If we changed it, we d need to force the implementor of a contraint...

👍 Thanks @balage1551. Thus, I am adding it to our v2 branch.

Todo: - [ ] extend HardXXXConstraint interface with default getName() method - [ ] implement .getName() in existing core constraints - [ ] change to .getName() method in reason tracker

No, unfortunately not.

@jie31best Thanks a lot. It seems that there are failing tests. Do you know why?

Nice, thanks, I ll have a look at this asap. In the meantime, would you mind to send us email for a CLA (https://www.graphhopper.com/contact-form/). Thanks.

Hi @toni-rajkovski, Thanks for your contrib. Would you mind to describe me how you use it? For debugging I guess? I only want to make sure that you do not...

As the method .getMostLikelyReason suggests it returns a reason that is most likely the actual reason. This also means that there is a probability that it returns the wrong or...

@muzuro Nice idea. Thank you. I see one major problem. This invites users to access StateUpdater and probably to modify states when checking constaints. This might yield lots of trouble,...