An Allure adaptor writes a result whose `StatusDetails` has `known`, `muted` and `flaky` all set to true. Which of the three survive into the generated report in Allure 2, and which in Allure 3?

## Written is not the same as honoured `StatusDetails` gives a writer three booleans -- `known`, `muted` and `flaky` -- and `allure-java` will serialise all three faithfully into the `-result.json`. What happens next is entirely up to the consumer, and the two live Allure majors make different choices. Writing a flag is not the same as a report honouring it, and that gap is where the surprise lives. | flag | Allure 2 (2.47) | Allure 3 (3.16.1) | |---|---|---| | `flaky` | carried into the report model | carried into the report model | | `muted` | never read | carried into the report model | | `known` | never read | parsed, then dropped | ## Allure 2: only the flaky flag crosses Allure 2's generator converts each parsed result into its own report entity. From `StatusDetails` it takes exactly three things: the `message`, the `trace`, and `flaky`. `known` and `muted` are parsed into the model object like every other field and then simply never consulted; the generator's own report entity has no place to put them. The practical effect: a result written with `muted` true renders in an Allure 2 report exactly like a result written without it. There is no visual difference, no separate bucket, no filter that finds it. If you have built a workflow around muting cases and you generate with Allure 2, the flag is doing nothing at all. ## Allure 3: flaky and muted cross, known does not Allure 3's reader for Allure-format results flattens `statusDetails` as it parses: `message`, `trace`, `actual` and `expected` become the result's error, and `flaky`, `known` and `muted` become top-level booleans on the raw result. So far all three survive. The loss happens one step later, when the raw result is converted into the report model. That conversion copies `flaky` and `muted`, each defaulting to `false` when absent, and does not copy `known` at all. Allure 3's report model has no `known` field; the closest thing it carries is a separate `resolution` field, which is populated by a different mechanism entirely. ## The one flag you can rely on `flaky` is the only one of the three that both majors carry through. If you are choosing which claim to encode on a result and you do not control which generator will read it, that is the one to use. The rest of the reasoning follows from three rules of thumb: 1. **Check the consumer, not the writer.** The result file will happily accept anything; the question that matters is whether the tool generating the report reads it. 2. **Absence in the report is not absence in the file.** When a flag does not show up, grep the raw `-result.json` before you assume the adaptor failed to set it. Very often the adaptor did its job and the reader threw the value away. 3. **Do not port a flag-based workflow between majors untested.** A `muted`-driven process that works on Allure 3 goes silent on Allure 2, and it goes silent without any error, warning or missing file -- the report simply generates as if you had never set anything. ## What to do when the flag you need is dropped You have three options and only three. Move to a consumer that reads the flag. Express the same claim through a field the target major does read, and group on that instead. Or accept that the claim lives only in the results directory and have whatever cares about it read the raw results rather than the generated report. What you cannot do is set the flag harder. There is no configuration key that makes Allure 2 read `muted`, and none that makes either major keep `known` in its report model, because in both cases the field is not being filtered out by a setting -- the code that builds the report entity never mentions it.