A CI job writes `executor.json` into the Allure results directory in a step that runs after the upload step. What does the stored run look like, and why does this ordering bug survive so long unnoticed?

## The upload is a snapshot, not a subscription The delivery step for a results directory copies what is on disk at the moment it runs. It does not watch the directory, it does not re-read it later, and there is no second chance — once the job ends, the workspace is reclaimed and anything written after the snapshot is gone. That makes the ordering of writes against the push a real, load-bearing property of the job, and it is one that nothing in the tooling enforces. ## Two kinds of file, written by two different actors This bug exists because a results directory has two populations of file with different authors: - **Per-test files**, written by the adaptor **inside the test process**: `-result.json` for each test, `-container.json` for the fixtures around them, `-attachment` files for the bytes. These are finished by the time the suite exits, so they are always present when the push runs. - **Whole-run files**, contributed by the **job** rather than by any test: `executor.json`, `environment.properties`, `categories.json`. Nothing in the test run produces them. Some step in the pipeline has to write them, and where that step sits relative to the push is a choice somebody makes — often without realising it is a choice. Only the second group can be late. And because the first group is never late, the run looks fine. ## Why the gap is silent Three things conspire: 1. **The push succeeds.** The directory is non-empty and well formed. There is nothing for the upload to complain about. 2. **The missing file is optional.** A results directory without `executor.json` is perfectly valid input; consumers simply have nothing to show for that section rather than raising an error. Absence is not a failure condition anywhere on this path. 3. **Everything a reader checks first is intact.** Counts, statuses, durations, failure messages and attachments are all per-test files, all present. Someone opening the run sees a normal run. So the defect has no symptom on the day. Its symptom appears the first time someone asks a question the missing file was there to answer — which build, which job, which environment produced this run — and by then dozens of stored runs have the same hole and none of them can be repaired, because the workspaces are long gone. ## Where the ordering actually breaks The common shapes are all mundane: - The publish step was added first, and the step that writes the whole-run files was appended later at the end of the job, where new steps naturally get added. - The job was refactored and the steps were reordered by someone reasoning about the suite, not about the snapshot. - The whole-run files are written by a step that only runs conditionally, so the ordering is correct on some runs and not on others — which produces the worst version of this, an intermittent gap nobody can reproduce. ## Fixes, in order of how well they hold 1. **Write and push in one step.** If the same step that performs the upload also writes the whole-run files immediately before archiving, the two cannot be separated by a later edit. This is the only fix that survives someone reordering the job a year from now. 2. **Assert the directory's contents before the push.** Check that the files the job promised are actually there, and fail the publish step if they are not. This turns a silent gap into a red step and costs almost nothing. 3. **Keep the ordering explicit in the job.** If the writes must stay in their own step, make the dependency visible rather than relying on the reader inferring it from step order. The general rule is worth stating on its own: **anything the job contributes to a results directory must land before the snapshot.** The push is the deadline for the whole directory, not just for the parts the tests wrote, and the only reliable way to keep a deadline is to not let anything be scheduled after it.