User Journey: Retry a failed or interrupted import

"The import stopped. I want to run the same file again and end up with the data imported once." The journey is done when the data is complete, nothing was written twice, and the person can say what the first attempt left behind.

The actor is the person who ran the import, signed in to the same party. The trigger is a failed step, a timeout, a lost connection, a crash, or a refusal partway through. The journey starts when the person reads the first attempt and ends when the retry succeeds, is abandoned, or is refused as a duplicate.

1. Read the first attempt. The person opens the run in the workflow progress screen, or reads the workflow instance in the shell. The rail shows each step with its state, and the failure is shown with the instance's error. For a trade import the step log lists each item error with its source file and ORE id. For a run import the shell prints the failure and the workflow instance. For market data the shell prints the section counts and the duplicate errors.
2. Decide what the first attempt left behind. The trade import keeps every trade that saved and fails only when all trades failed. The run import undoes curves, market data, pricing engines and the run document, but not the conventions it stored. The market data import keeps every section that had no duplicate error.
3. Retry the same file. On the progress screen the person presses Retry. The system resumes the same workflow instance from the failed step, and the earlier steps are not run again. In the shell the person re-runs the same verb with the same request_id; that starts a new instance, and the uploaded tarball is still in the bucket, so no upload is needed.
4. Check the counts against the first attempt. The person compares the saved counts with the first attempt. For trades, the second run creates new trade ids, so the total rises by the number of trades that saved in both.
5. Repair or abandon. If the retry duplicated trades, the person deletes them by hand, or imports into a fresh book and discards the first one. If the run import stored conventions, the person decides whether to keep them or replace them.

The retry prints a new workflow instance id, a completed step and the saved counts. The person can read the final state in the trade list, the conventions screens or the market data screens. The data is complete.

A refused retry names the file and the reason. A retry whose budget expires leaves the workflow running and the shell says so; the person can read the instance later. A retry of the trade import prints "saved N trade(s)" again and does not warn that N of them already existed. A retry of the run import stores another configuration binding under the same report definition. Market data duplicates are refused only when the person passes --duplicates-are-errors; otherwise the import reports the counts it stored.

• A retry must never apply the same trade twice without the person knowing. Today it can, because no trade is matched by its ORE id.
• A retry must never apply the same conventions twice as two versions when the file is unchanged. The save replaces by key today, which is the one import path that is safe to repeat.
• A retry must never overwrite a newer row with an older file without saying so.
• A retry must never resume from a step that already ran and then run it again.
• A failed attempt must never be deleted or hidden. The person needs its counts to know what remains.

The workflow progress screen shows the rail, the steps and the retry control. It is the one screen that carries a retry today. The shell has no retry verb: the person re-runs the import verb, which starts a new workflow instance. No web screen lists past imports for a party.

1. No idempotency key on the trade import. request_id names the tarball, not the import. A second call starts a new import.
2. No trade identity check. Nothing refuses a trade the party already holds under the same ORE id.
3. No resume. The trade import is one workflow step, so a retry redoes all of it. The run import is also all or nothing at the file level.
4. No import history. There is no list of past attempts per party, so the person cannot tell a first attempt from a retry.
5. No post-failure summary. The person has to reassemble the first attempt's state from a workflow log and a service reply.

• See what a failed family left behind - the read that precedes the decision to retry.
• Review an import before it is applied - the preview that would avoid the retry.
• Import a portfolio from ORE - the trade import in detail.
• Promote an environment between systems - where a retry is a promotion step.

• Conventions journeys
• Trade journeys

• Data exchange journeys - the group hub.