[midPoint-git] [Evolveum/midpoint] ed91a2: Fix regression causing ID Match correlation test f...

[Andrej]

  Branch: refs/heads/master
  Home:   https://github.com/Evolveum/midpoint
  Commit: ed91a282380d204dcb3d230144a034bd5136ddec
      https://github.com/Evolveum/midpoint/commit/ed91a282380d204dcb3d230144a034bd5136ddec
  Author: Andrej Zan <andrej.zan at evolveum.com>
  Date:   2026-04-08 (Wed, 08 Apr 2026)

  Changed paths:
    M model/model-api/src/main/java/com/evolveum/midpoint/model/api/correlation/CompleteCorrelationResult.java
    M model/model-impl/src/main/java/com/evolveum/midpoint/model/impl/correlation/CorrelationServiceImpl.java
    M model/model-impl/src/main/java/com/evolveum/midpoint/model/impl/sync/CorrelationProcessing.java

  Log Message:
  -----------
  Fix regression causing ID Match correlation test failures

**What**

Fix a regression brought in by commit number #96b516ba.

**Why**

The regression was caused by two reasons:

- The ID Match correlator state was not correctly stored in case when no
  owner exists (with certainty).
- The correlation result delta was created with wrong base (before)
  object, what causes that the delta optimization removes the correlator
  state item from it also in cases when it should stay there.

Technically, the root cause is the second reason. When the second reason
"disappears", the first one does not cause any troubles. But for the
sake of consistency, this change solves both of them.

**Details**

It all boils down to the delta optimization. The synchronization context
(the failing tests uses an import task, which in turn uses
synchronization code), contains two copies of the currently processed
shadow. One is the "read only" state before any changes done by the
synchronization, and the second one is "working" shadow, which is
modified during the process.

In case of ID Match correlator, the correlator state is not only stored
by the application of the correlation results delta, but it is also
directly added to the "working" shadow by the correlator itself.

When further in the synchronization process the delta is created from
the correlation state, we need to chose some shadow as its base (the
before object). When we chose the "working" shadow (the regression), the
delta optimization will cause, that the correlator state item delta will
be optimized out, because the same correlator state is already present
in the working shadow (see above).

Above may seem right at the first sight. But there are scenarios, like
in the failing tests (btw. it's for example this suite
`TestIdMatchCorrelationSimpleDummy`), where we need the correlator state
item delta, even though it already is in the "working" shadow.

My **presumption** is, that in this cases (e.g. "uncertain" correlation
scenario), the synchronization process does not proceed with the
"import" of the shadow (because obviously it does not know to what
focus to import it). But when there is no import, I assume the "working"
shadow is not used to update anything in the repository. And because the
correlation result delta does not have (after optimizations) the
correlator state neither, the correlator state is not saved at all in
the shadow.

The simple solution to this issue was to - as it was before the
regression commit - to us the "original" (before) shadow as the base for
the correlation state delta.

**Task**: 11168



To unsubscribe from these emails, change your notification settings at https://github.com/Evolveum/midpoint/settings/notifications