Report comparison cleanup recovery state
This commit is contained in:
@@ -56,7 +56,8 @@ When publication has committed its new bundle, application results contain the
|
||||
absolute manifest, data-package, and successful report paths even if removal of
|
||||
the previous sibling backup then fails. That cleanup failure is still returned
|
||||
as an operational error rather than treating the new bundle as unpublished;
|
||||
the returned error retains the recovery path and underlying filesystem cause.
|
||||
the returned error identifies the observed recovery state and includes a path
|
||||
only when cleanup left a sibling behind.
|
||||
|
||||
## Boundaries And Verification
|
||||
|
||||
|
||||
@@ -31,9 +31,11 @@ not incorporate its basename.
|
||||
The new bundle is committed only after the staged directory has been installed
|
||||
at the target. From that point its artifact paths are authoritative: a failure
|
||||
to remove the retained sibling backup does not roll back the new bundle.
|
||||
Publication returns an inspectable cleanup error with the absolute backup path
|
||||
and underlying filesystem cause so an operator can recover or remove that
|
||||
backup manually.
|
||||
After a cleanup failure, publication inspects the sibling without masking the
|
||||
original filesystem cause. Its inspectable cleanup result distinguishes a
|
||||
complete recognized recovery bundle, partial remnants, an absent sibling, or
|
||||
an uninspectable state. A recovery path is reported only when something
|
||||
remains; only a complete recognized bundle is suitable for rollback recovery.
|
||||
|
||||
The application preflights before prompt inspection and collection, then
|
||||
preflights again before publication. A cancellation or any failure before the
|
||||
|
||||
Reference in New Issue
Block a user