$subject
$subject : string
A subject somebody changed while the restore was being decided.
Not the edits a rollback is meant to discard. Restoring a node to what it was on Tuesday discards Wednesday and Thursday by definition; that is what was asked for and it is not a conflict. The dangerous case is narrower: a plan is built, a person reads it, approves it, and in between somebody edits one of the subjects it covers. The plan they approved no longer describes what is there, and applying it overwrites an edit nobody saw.
So the comparison is against the moment the plan was made, not against the restore target. On a plan applied immediately there are no conflicts at all, which is correct; on one that sat waiting for a second approval there may be several.
Detected locally and for nothing: the subject index already records when each subject was last written. No reads, no replay.
A conflict does not fail a restore. The subject is skipped and named, the same shape as a degraded one, unless the scope opted in to overwriting it.
__construct(string $subject, int $changedAt, int $plannedAt) : mixed
Constructs a conflict.
| string | $subject | Subject path, such as "entity/node:42". |
| int | $changedAt | Unix microseconds the subject was last written. |
| int | $plannedAt | Unix microseconds the plan was built. |