A transfer attempt is not an accepted submission.

A transfer starting, bytes leaving a device, and a shared system accepting an operation are different events. The application should identify which event changes the user-facing status. A progress indicator may describe transfer activity while leaving acceptance unresolved.

The service contract also matters. A response might mean that information was received for later processing rather than immediately available to other users. The product explanation needs to reflect that distinction.

If a response does not return, the client may not know whether the operation was accepted. That uncertainty is different from a clear rejection. Treating both as failure can encourage a user to create a second item when the first may already exist.

The design needs an appropriate way to resolve the status, such as checking the operation’s identity or applying an agreed retry rule. The correct method depends on the service and the intended action.

The person performing the task needs a useful next step. They may be able to leave the item queued, return later, or seek help. Avoid telling them to resubmit blindly when the application cannot distinguish another attempt from new work.

Messages should also distinguish a temporary interruption from a business rule that prevents acceptance. A required field and a lost response call for different actions.

Review a successful response, a clear rejection, an interrupted response, and a delayed acknowledgment. Observe the local state and the shared system separately. A screen message alone cannot establish what occurred remotely.

Record which conditions were tested and what the observations support. If later processing or visibility to another user matters, include that in the experiment explicitly. Confirmation should describe the evidence available, not the outcome the team hopes occurred.