What a product should tell people when an import, save or background job is interrupted.
Designing a useful failure state
A failure message belongs to the workflow it interrupts. The person reading it needs to know what happened to their work and what they can do next.
Preserve the work first
An interrupted import should retain the original source and any completed steps. A failed save should keep the local draft visible. The interface should distinguish a safe local draft from a confirmed server save.
Give one useful next step
Explain whether the person should wait, correct an input or try again. Avoid showing a generic retry button when another attempt cannot change the result.
Make the state visible
Progress, saved changes and failure messages should describe the same operation. This makes an unfamiliar problem easier to understand without asking the person to learn how the software works.