Run a report and watch it finish prototype
Table of Contents
| Item | Where |
|---|---|
| Prototype | the prototype |
| Gemini review | none |
| Group | Reporting prototypes |
1. Summary
This prototype argues how a person starts a run and then knows when to stop
waiting. It carries three structural variants switched with ?variant, and it
answers to
Run a report and watch it finish.
It is throwaway. It reads no service, and the run it shows advances on a scripted timer so that the waiting can be judged at all.
2. Detail
2.1. The question
Starting a run is easy to draw. Waiting is not. The journey is over when the run reaches a terminal state, and the open question is whether that state arrives where the person is looking or somewhere they have to go back to.
2.2. The three variants
Switch with the bottom bar, or with ?variant.
| Variant | Name | The structural argument |
|---|---|---|
A |
Modal and notify | Starting a run is a confirmation over the catalogue, and the run then reports itself in a strip so the person can keep working. Waiting is someone else's job. |
B |
Run theatre | Starting a run opens a dedicated view of that run, with the six phases advancing left to right and the current one live. The person stays until it is terminal. |
C |
Queue-first | Starting a run drops a row into a queue of that person's runs, each advancing in place, so several can be watched together. |
2.3. Six phases, seven steps
The pipeline has six phases: Pre-processing, Submission, Execution, Retrieval, Post-processing, Finalisation. The workflow that implements them has seven steps, because pre-processing is four steps rather than one and retrieval and post-processing are a single step rather than two. The page shows both and says which is which, because a reader who confuses them will misread every run that has a step retried.
Execution runs on a worker node and is not a step any ORE Studio service performs; the services submit the work and wait. The page marks that phase as the worker node's rather than the platform's. Only finalisation touches the state machine.
2.4. The two endings that matter
A run reaches a terminal state with output_message, and the successful one
reads exactly Report execution completed. A run can also complete and still
carry errors, so the terminal state says so at the moment it arrives rather than
leaving it to be discovered later. A failed run terminates with a report-scoped
error rather than a phase stuck mid-flight.
2.5. Driving it
The phases advance on a timer, one every 700 milliseconds, so a run reaches its end in about 4 seconds. There is a control to run the demonstration again. The timer is the point: a static picture of a half-finished run cannot be judged.
2.6. What is fake
Everything, and the page is explicit about the part that matters: the per-phase
position the ladder shows does not exist as a read. It lives in ores.workflow,
and no reporting read serves it. The phases are scripted, nothing reads a
server, and the definitions, parties, timings and errors are mock.
2.7. Where the code lives
doc/prototypes/reporting/run-a-report-and-watch-it-finish/. Three files, plain
HTML, CSS and JavaScript, no framework and no build step.
2.8. The verdict
None yet. This page is on the branch that proposes it and waits for review. The
phase ladder is the strongest part of B and the most likely thing to be taken
into whichever variant wins.
2.9. What it does not settle
Where the progress comes from. The screen can draw a run advancing, but the server does not yet serve a run's current phase, so the real build needs either a workflow read or a reporting-side projection of one. That is a server question, not a layout one.
3. See also
- Reporting prototypes — the group, and the axis this prototype turns on.
- Reporting journeys — the five journeys these answer to.