User Journey: Reproduce a defect from an exported environment

"I want the failing run from the reporting environment here, with the same trades, conventions, market data and job inputs, so I can watch it fail and then fix it." The journey is done when the same job, on the same data, fails the same way in the development installation.

The actor is a support engineer or developer who holds the permissions every import in this journey needs in the development installation, and who is signed in to the party the defect belongs to. The trigger is a reported defect, a failed report run, or a job whose output cannot be explained. The journey starts with files received from the reporting environment and ends when the job is reproduced or when the gap that prevents reproduction is named.

The journey runs in the shell. No web screen accepts an ORE upload today.

1. Gather the export. No single command writes a whole environment. The person collects the parts: ore export for the trades under one book or portfolio, ore export-run for the run document and the conventions, curves, today's market and pricing engines it binds, marketdata export for the quotes and fixings, and compute download-input for the job's input bundle. The engine package comes from the package_uri of the app version the job ran, checked against its sha256. The job itself is not exported. Its definition is rebuilt in the target.
2. Upload the trades. The person runs ore upload <src_dir>. The system packs the directory as a tarball, uploads it to the ore bucket under ore/imports/{request_id}.tar.gz, and prints the request id. The person may mint the request id so a retry uploads over the same object.
3. Import the trades. The person runs ore import <request_id>, naming the parent portfolio and, for a defect outside the official tree, the open sample sandbox the import should land in. The system starts workflow.v1.ops.ore_import and returns a workflow instance id. The shell waits for the step and prints its log.
4. Import the run configuration. The person runs ore import-run <report_definition_id> <src_dir> with the exported directory. The system parses ore.xml and every file it names before the first write, then binds and stores the documents under the report definition.
5. Import the market data. The person runs marketdata import with the two files. The system stores the series, observations and fixings and reports the counts.
6. Reproduce. The person runs the job again in the development installation with the imported input bundle and engine package, or reruns the report definition. The system produces the failing output or the failing step.

The shell prints the upload path and request id, the workflow instance id, the step log with the counts of currencies, portfolios, books and trades it saved, the run import's stored file count, and the market data counts. The rerun fails the same way as the original, and the person holds the input bundle that caused it.

A trade that cannot be saved is reported by source file and ORE id and does not stop the other trades. The step then completes with warnings and the saved trades stay. A refusal that stops the import names the step or the file. If every trade fails, the step fails and the compensation deletes the currencies, portfolios, books and trades it created. A missing ore.xml, a file the run document names but the input does not hold, or an XML parse error is refused before the run import writes anything. A timeout leaves the workflow running, and the shell says the import did not complete.

• The development import must never write to the reporting installation.
• A trade must never land in a party other than the session's party.
• A family or convention the server cannot store must never disappear without a line in the result. FX conventions are skipped today, and the response lists them.
• A partial import must never be reported as complete.

There is no screen. The entry points are the shell verbs ore upload, ore import, ore import-run, ore export, ore export-run, marketdata import, compute download-input and the workflow run log. The web UI shows conventions and market data but has no import or export route.

1. No whole-environment export. The person must find and run four export verbs and write down what each produced. There is no command that writes one dated bundle and no manifest that names the versions of its parts.
2. No job export. A compute job is dispatched and its inputs are stored, but no verb writes the job definition, its batch and its app version as a file that another installation can import.
3. No cross-component transaction. The trades, the conventions and the market data land in three services and three imports. A failure in the third leaves the first two stored.
4. No preview. The import reports what it saved after the fact. It cannot show the plan before the writes.

• Import a portfolio from ORE - the trade half of the same import.
• Export for archival - the export side, with the same gaps.
• Diagnose and reproduce a failure - reads the failed job before the data is moved.
• See what a failed family left behind - after an import refuses.

• Conventions journeys
• Trade journeys

• Data exchange journeys - the group hub.
• doc/knowledge/journeys/trades/journey_import_a_portfolio_from_ore.org