ReportPortal's `CreateClustersRQ` carries only `launchId` and `removeNumbers`. What does `removeNumbers` change about the clusters you get back, and how does each setting fail?

## The request has exactly one knob `CreateClustersRQ` -- the body that starts cluster generation for a ReportPortal launch -- carries **two fields and nothing else**: `launchId`, which is required and names the launch to cluster, and `removeNumbers`, a plain boolean. There is no similarity threshold on this request, no log-line count, no cluster cap. Whatever the grouping does, `removeNumbers` is the only lever the caller gets over it. `removeNumbers` is a **primitive boolean**, so a request that simply omits the field is asking for `false`: group the failure messages exactly as they arrived. ## What each setting does - **`false` -- group on the message as it stands.** Two failures land together only if their failure text compares as the same. Any digit that varies between runs is part of that text: an order id, a port, a row count, an elapsed-milliseconds figure, a line number, a generated account number. - **`true` -- strip digits before comparing.** Messages that differ *only* in their numbers collapse onto each other, so one defect reported a hundred times with a hundred different ids becomes one cluster instead of a hundred. The two settings fail in opposite directions, and both failures are ordinary: | setting | what merges | how it goes wrong | |---|---|---| | `removeNumbers` false | only byte-identical failure text | **too narrow** -- every run mints new clusters, and a cluster list of singletons tells you nothing | | `removeNumbers` true | text that differs only in digits | **too broad** -- failures whose only distinguishing feature *was* a numeric code merge into one bucket | The second column is the part worth rehearsing in an interview. Stripping numbers is not free: if the meaningful difference between two failures is a status code, an error number or an exit code, normalising it away is exactly the wrong move, and you get one large cluster that quietly contains two unrelated problems. ## The project setting underneath it A project stores its own value under the analyzer settings, as `analyzer.uniqueError.removeNumbers`, alongside `analyzer.uniqueError.enabled` which decides whether this kind of clustering is on for the project at all. When a request arrives, the value on the request is **applied over the project's stored value for that one generation**. It is not validated against it and it does not update it. That has a practical consequence worth stating plainly: 1. The project setting is the default that automatic, unattended generation uses. 2. The request flag is a per-run override, so you can try the opposite normalisation on one launch without changing anything for anyone else. 3. Because the override is not persisted, the next automatic run reverts to the project's value -- an experiment you liked has to be promoted into the project setting deliberately. ## When the knob cannot help you `removeNumbers` normalises **digits**. It does nothing about any other varying token, and real failure messages are full of them: - a hostname or pod name with a random suffix - an identifier made of letters as well as digits - a temporary file path with a generated segment - a stack frame from a synthetic proxy class If those are what is splitting your clusters, flipping the flag changes nothing measurable, and the fix has to happen earlier -- in what the failure message says by the time it reaches the report. Recognising that boundary is what separates "I tried the flag" from "I understood what the flag does". ## How to tell whether the flag helped Because a full generation rebuilds a launch's clusters from scratch, the experiment is cheap and repeatable on the same launch: generate with one setting, read the cluster list, generate again with the flag flipped, read it again, and compare the `matchedTests` distributions. A good outcome is a small number of clusters with counts that look like the number of distinct problems you believe the launch actually had. A bad outcome in either direction is visible immediately -- one enormous count, or a page of ones.