In ReportPortal, when auto-analysis puts a defect group on a failure it also sets `autoAnalyzed`. What does that boolean record, where does it live, and what does it deliberately not say?

## Where the flag lives, and why that matters A ReportPortal test item that failed carries an **issue**, and it is the issue — not the item — that carries the triage state. Two booleans sit there beside the defect group: - **`autoAnalyzed`** — this group was set by analysis rather than by a person. - **`ignoreAnalyzer`** — this failure is to be kept out of analysis. Both are on `Issue` as it crosses the API and on `IssueEntity` in storage, backed by the columns `auto_analyzed` and `ignore_analyzer`. Candidates routinely look for them on the test item and cannot find them; the item has a status, the issue has the verdict and the provenance. That placement is deliberate. A passing item has no issue at all, so there is nothing to say about who labelled it. The moment a failure acquires a triage state, it acquires a record of where that state came from. ## What gets written when analysis wins When the analyzer returns a match for an item, the server does not patch a field in place. It rebuilds the issue: it resolves the returned locator to the project's issue type, sets the group, sets `autoAnalyzed` to true, and carries the existing `ignoreAnalyzer` value across unchanged. It then recomputes the project's defect counters, because a failure has just moved from one group into another. Two consequences fall straight out of that: 1. **The flag is set as part of applying the label, in the same write.** You never see a machine-set group without the flag. 2. **It is a rebuild, not a merge.** The values that survive are the ones explicitly carried across. ## Provenance is not confidence This is the distinction interviewers are usually fishing for. `autoAnalyzed` answers *who*, never *how sure*: | question | answered by `autoAnalyzed`? | |---|---| | Did a machine set this group? | yes | | How closely did the failure match? | no | | Which past failure was it matched against? | no | | Under what settings was the match made? | no | | Should I trust this label? | no | The scores, the settings and the matched candidate live on the suggestion record, not here. One bit cannot carry them, and reading the flag as a quality signal is how teams end up trusting machine labels more than they have earned. ## What keeping provenance buys you Because the two populations are separable, a re-analysis run can be aimed at one of them. `AnalyzeItemsMode` names which items an analyze run should include — `TO_INVESTIGATE`, `AUTO_ANALYZED`, `MANUALLY_ANALYZED` and `IGNORE_IMMEDIATE`, of which a request may ask for the first three. In practice: - **`TO_INVESTIGATE`** takes the undecided failures and tries to label them. Nothing already decided is touched. - **`AUTO_ANALYZED`** takes exactly the machine-labelled ones. Those items are pulled out of the analyzer's index and their issues reset before the run, so a bad batch of machine labels can be redone from scratch. - **`MANUALLY_ANALYZED`** does the equivalent for the hand-set ones — which is why nobody runs it casually. Without the provenance bit none of that is expressible. You would be able to say "re-analyse this launch" and nothing finer, and every re-run would sweep away work people did by hand. ## The trap: the flag is not cleared for you When a person edits an issue through the update endpoint, the value written for `autoAnalyzed` comes from the **request body**. It is not recomputed and not automatically cleared. A client that reads an issue, changes the group, and sends the whole object back will happily re-assert `autoAnalyzed: true` on a label a human just chose by hand. The practical effects are worth stating plainly: - Your two populations can silently blur, so the `AUTO_ANALYZED` re-run stops meaning what you think it means. - A dashboard split by provenance drifts without anything logging an error. - The fix is on the writing side: whoever edits an issue is responsible for sending the flag that is now true. The item does separately record which user made the change, and the activity trail keeps the before and after, so the truth is recoverable — but not from this boolean alone. ## How to answer it well Say what it is (provenance), where it is (on the issue, not the item), what it is not (a confidence), and what it enables (targeted re-analysis by mode). If you have operated ReportPortal, add the update-endpoint trap — it is the kind of detail that only shows up once you have watched a well-meaning integration flip the flag on a whole project.