Recently I have modified multiple resources after the upgrade of a midPoint deployment to 4.4 LTS. I wanted to replace legacy $user and $account variables with $focus and $projection, or even omit the variables where they are the default context. Alas, I got overzealous and I also accidentally removed variables where they are necessary. The next run of a reconciliation task led to the following error:
Runtime error in projector: Cannot determine definition from content in Source(null: old=null, delta=null, new=null)
Now, this is not an error you want to see. Of course, I knew I broke a mapping. But which one? And why didn’t midPoint please me with a more typical mapping error like this one:
Cannot determine definition from content in Source(null: old=null, delta=null, new=null) in inbound expression for dn in resource:<oid-here>(<resource-name>)
Here I can see the resource and the attribute (dn) and I know I made a mistake in one of the additional source mappings. But from the original error I could only deduce I broke a less traditional mapping. But which one? Without a doubt, you don’t want to see an error like this.
MidPoint should do better. However, midPoint is in constant development, it is constantly being improved and also extended with new behavior. Things change, and sometimes they are not working the best way the first time. MidPoint likely will do better, because we recorded the issue into our bug tracking system.
No, this is not why open source is cool. 🙂 This can happen with any software, including a proprietary one. Usually you can report issues, sometimes even in a public bug tracking system. But sometimes you cannot. Generally speaking, good luck with the support from some renowned companies.
Open source software is cool, because you actually may use the source code to figure out the problem. Let’s look into
the logs:
2022-11-21 11:29:54,207 [MODEL] [pool-3-thread-30] ERROR (com.evolveum.midpoint.model.impl.lens.projector.Projector):
Runtime error in projector: Cannot determine definition from content in Source(null: old=null, delta=null, new=null)
java.lang.IllegalArgumentException: Cannot determine definition from content in Source(null: old=null, delta=null, new=null)
at com.evolveum.midpoint.prism.util.ItemDeltaItem.<init>(ItemDeltaItem.java:71)
at com.evolveum.midpoint.repo.common.expression.Source.<init>(Source.java:41)
at com.evolveum.midpoint.model.common.mapping.MappingParser.parseSource(MappingParser.java:215)
at com.evolveum.midpoint.model.common.mapping.MappingParser.parseSources(MappingParser.java:108)
at com.evolveum.midpoint.model.common.mapping.MappingParser.parseSourcesAndTarget(MappingParser.java:59)
at com.evolveum.midpoint.model.common.mapping.AbstractMappingImpl.prepare(AbstractMappingImpl.java:718)
at com.evolveum.midpoint.model.common.mapping.AbstractMappingImpl.evaluateTimeValidity(AbstractMappingImpl.java:641)
at com.evolveum.midpoint.model.impl.lens.projector.mappings.MappingEvaluator.evaluateMappingSetProjection(MappingEvaluator.java:215)
at com.evolveum.midpoint.model.impl.lens.projector.focus.InboundMappingsEvaluation$ProjectionMappingsCollector.evaluateSpecialInbounds(InboundMappingsEvaluation.java:763)
at com.evolveum.midpoint.model.impl.lens.projector.focus.InboundMappingsEvaluation$ProjectionMappingsCollector.collectOrEvaluateProjectionMappings(InboundMappingsEvaluation.java:230)
at com.evolveum.midpoint.model.impl.lens.projector.focus.InboundMappingsEvaluation$ProjectionMappingsCollector.collectOrEvaluate(InboundMappingsEvaluation.java:185)
...An interesting part here is the stack trace – all those lines starting with the at word. You look at it, and suddenly you hear that distant voice: “Use the source, Luke!”, and you know what to do. Sure, oftentimes the stack trace is frighteningly long, but when looking at the bug in midPoint we should focus on the lines containing com.evolveum, and simply go from the top to the bottom.
An important thing to note: know your version of midPoint and use the right version of source! In this case, it was support-4.4 branch, so let’s look at… MappingParser and line 215 for instance. You don’t even need any development environment!
- Go to:
- In the branch dropdown (which normally says master), find your by either a tag or a branch name – in my case it’s the branch support-4.4.
- Now use the Go to file button and enter the name of the class (MappingParser in our case).
- Then find the line 215 and check it and its immediate surroundings for any clues.
Too bad that there are none. But now you just have to repeat the last two steps – Go to file and find the line. Going lower, you’ll soon encounter the file named InboundMappingsEvaluation and its line 230. Here is a direct link to the suspicious place. “Aha!” I hear you say. “So it’s validFrom mapping in activation!”, and sure it is. I’m too embarrassed to admit what I did wrong there, but I fixed it and walked away with a great story about open source!
If GitHub web is not helpful in your case, you can always clone the repository locally and investigate any particular revision, if necessary.
Looking at the source code is not for everybody and there are other ways to locate a bad mapping. Simply don’t change bazillions of them at once. Although, that makes the process of cleaning up a lot of mappings very long. You can also bisect the problem – revert half of the configuration changes, test whether it helped, then bisect further. But that also takes time. Sometimes looking at the source is actually pretty fast. Not always, of course.
But the point is, with open source software you at least have that option – and it can help you when everything else fails.