$target
$target : string
What a restore actually did, against what it planned to.
Separate from the plan because the two disagree in exactly the cases that matter. A subject that planned as restorable and then failed to write - a validation constraint, a missing bundle, a field that no longer exists - is the interesting half of a restore, and folding it back into the plan would hide it.
__construct(string $target, string|null $snapshot = null, list$restored = [], array $skipped = [], array $failed = [], string|null $refused = null, float $seconds = 0.0) : mixed
Constructs a result.
| string | $target | Commit the restore targeted. |
| string|null | $snapshot | Commit taken before the restore, so it can be undone, or NULL when none was taken. |
| list |
$restored | Subject paths written back. |
| array |
$skipped | Subject path keyed to why it was left alone. |
| array |
$failed | Subject path keyed to why writing it did not work. |
| string|null | $refused | Why the restore did not start, or NULL when it ran. |
| float | $seconds | How long it took. |
outcome() : string
The outcome an audit row records.
A restore with any failed subject is FAILED even when most of it worked, because a partly applied rollback is a state the operator has to know about and "succeeded with notes" is not a state anyone reads.
One of the RestoreAudit outcome constants.