Agree what the system should do when the outcome of a transfer is unknown. A missed response leaves a question to resolve: what evidence establishes whether the requested operation started, completed, failed or remains in progress?
Write the recovery procedure alongside the normal interface contract. Identify who holds the authoritative operation record, which physical conditions must be checked and who can authorize the next action. Avoid making a new movement the default way to discover the result of the previous one.
Separate waiting limits from operation outcomes
Give each waiting limit a purpose: admission response, progress update, operation result or connection supervision. State what the consumer may conclude when that limit is reached. A waiting limit can trigger investigation or escalation without asserting a physical result that has not been observed.
For background on result availability, the ROS 2 Actions design describes configurable result caching. A reconnecting client therefore needs the actual interface's retention and restart behavior, rather than an assumption that every old outcome remains available. ROS 2 Actions design: result caching
Record the recovery decisions
The table is a project review aid. Populate it with the controller and equipment owners; it is not a procedure authorizing operation of an unknown machine.
| Condition to review | Evidence to seek | Decision and owner to agree |
|---|---|---|
| No admission response | Request identity and whether the receiver recorded it | How to query or reconcile the request before a retry |
| Feedback becomes stale | Last confirmed state, its age and available controller status | When to pause dependent workflow and escalate |
| Result response is missing | Authoritative result, request history and relevant physical state | How an uncertain outcome is resolved |
| Connection returns | Session/configuration identity and current operation record | Conditions for restoring normal command handling |
| Controller restarts | Preserved records, lost state and initialization status | Who determines whether reconciliation is complete |
| Cancellation is requested | Actual cancellation outcome and remaining physical conditions; a cancellation response alone does not establish that motion has stopped | Who confirms the resulting state under the applicable equipment procedure |
| Duplicate request appears | Identity, retained result and scope of duplicate detection | Reject, return known result or follow another agreed rule |
| Evidence cannot resolve state | Known facts, unavailable observations and affected equipment | Named human escalation and release authority |
Where a record is missing, document that limitation. Do not turn an empty result history into proof that no physical operation occurred.
Define the boundaries of a retry
Agree the identity used to associate requests and responses, how long relevant records are retained and what happens across restarts. Document which operations permit a retry under which confirmed conditions. Treat the duplicate-handling rule as an interface requirement to verify, not a promise inferred from a request ID alone.
Review these conditions with the hardware interface scope. Include the instrument's readiness and occupancy responsibilities where they affect the next handoff. Customer workflow logic and agreed instrument software remain with the customer team.
Use a recovery release record before another movement
When the operation outcome is uncertain, create one release record before the scheduler issues another movement. The record should combine interface evidence with the physical checks available for the agreed work package. Use the completion evidence worksheet to keep platform completion separate from instrument readiness and other external conditions.
| Release record | Minimum entry | Decision value |
|---|---|---|
| Interruption identity | Request reference, operation, interface/configuration revision and agreed time basis | Prevents evidence from different requests or configurations being combined |
| Last confirmed interface record | State or result, source, timestamp or sequence, and freshness limit | Separates a retained record from an assumption about the current physical state |
| Physical observation | Available position, occupancy, gripper, payload or instrument condition; observer and method | Shows which relevant conditions were actually checked and which were not observable |
| Unresolved uncertainty | What remains unknown and which actions are prohibited until it is resolved | Stops a retry from becoming an uncontrolled diagnostic movement |
| Reconciliation outcome | Not started; active (accepted, executing or canceling, as defined by the agreed interface); completed; failed; cancelled; or still unknown, with supporting evidence | Provides one agreed interpretation for the platform and scheduler teams |
| Next allowed action | The permitted action, its preconditions and the responsible executor | Converts the review into a controlled recovery step rather than a general permission |
| Release authorization | Named role, decision time, applicable procedure and linked evidence record | Identifies who may close the hold and what remains in the audit trail |
An active classification is not a terminal outcome or permission to start another physical action. Keep affected dependent actions on hold, continue monitoring through the agreed interface or use the authorized recovery path defined for the project.
If the available evidence cannot establish the current operation state or a terminal outcome, keep the unresolved state unknown, maintain the hold on affected dependent actions and escalate to the named authority. Do not replace a missing observation with a normal completion value.
Turn the table into acceptance evidence
Select interruption cases with the responsible engineers and include them in the agreed hardware FAT plan. Define the test arrangement, permitted fault injection, expected records and restoration procedure before execution. Perform physical recovery only under the applicable equipment procedures and authorized supervision.
For each case, retain the configuration, request reference, observed responses and release decision. Relate that evidence to the configuration and traceability record. Before freezing the acceptance criteria, add each gap in observation, record retention or ownership to the interface open-item list, with an owner and the evidence needed to close it.