I need a better restart state for our sleeve transfer. FR10 may release the sleeve before the application saves the next pocket. The file still points at the old destination. How should the recovery design represent that uncertainty?
Ask the programmer to distinguish an unstarted transfer from one with an unknown outcome, and have the cell team define how the operator reconciles the latter before another movement is requested.
They are adding transfer stages and an unknown-outcome case. I also found that opening the helper currently calls the same function as resume. That connection is being removed.
Include that opening behaviour in the test request, along with an application crash after release but before the save, so the change is checked against the actual failure you found.
Offline reopening now leaves the uncertain transfer waiting for reconciliation. It does not send another request. Physical recovery and operator instructions still need review with the integrator.