skip to content

ReportPortal records `rp.cluster.lastRun` after clustering a launch. Where does that key live, and what question does it let you answer?

level: middleimportance: nice to knowfreq 26%

answer

  1. the prefix is misleading here
  2. recorded state, not configuration
  3. written onto the launch after generation
  4. a timestamp, replaced each full run

basics

~20 s

It lives as a system attribute on the launch itself, written by the clustering pipeline and replaced on each full generation. It answers whether and when that launch was clustered -- nothing about the clusters produced.

solid answer

~40 s

`rp.cluster.lastRun` is a **launch attribute**, not a server configuration property, and that is the whole trap in the name: ReportPortal's real server properties do share the `rp.` prefix, so the key looks like one of `rp.datasource` or `rp.searchengine` and is not. It is written by the clustering pipeline after a full generation for a launch, carries the moment it ran as an epoch-milliseconds value, and replaces any previous value, so there is exactly one per launch. Putting it in a config file does nothing, because nothing reads it from there. What it buys you is the ability to distinguish "clustering never ran on this launch" from "clustering ran and produced nothing" -- two situations the cluster list alone renders identically. It says nothing about how many clusters exist or how good they are.

go deeper

for a junior

Recall that the key names a moment recorded on a launch after clustering, and that it is data written by the product rather than something you configure.

for a middle

Explain why the rp. prefix misleads: real server properties share it, but this one is a system launch attribute, replaced on each full generation and read from the launch.

for a senior

Use it operationally -- to tell a launch that was never clustered from one clustered with no result -- and know it is dropped when launches are merged.

for a principal

Take a view on naming conventions that let recorded state and configuration share a prefix, and what a silently-ignored config line costs a team over time.

## What the attribute is After ReportPortal finishes generating clusters for a launch, the pipeline writes a **launch attribute** with the key `rp.cluster.lastRun`, whose value is the moment that generation ran, recorded as an epoch-milliseconds figure. Any previous value for that launch is removed first, so exactly one such attribute exists per launch and it always reflects the most recent full generation. It is written as a **system** attribute, which is the mechanically important part: it is not one of the attributes a person or a CI job put on the launch, and it is not meant to be read as a label alongside them. It is bookkeeping the product left on the launch about itself. ## Why it is not a configuration property This is where the name misleads, and it is worth being explicit because it is a genuine trap. ReportPortal's **server** does have configuration properties under an `rp.` prefix -- `rp.datasource`, `rp.searchengine`, `rp.requestLogging` and others. `rp.cluster.lastRun` shares the prefix and looks exactly like one of them. It is not: - It is **data on a launch**, written by the clustering pipeline at runtime. - Setting it in a configuration file, an environment variable or a properties file does nothing at all, because nothing reads it from there. - You do not configure it, choose its value, or turn it on. It appears because clustering ran. Anyone who writes it into a deployment config has produced a line that will never be read and a belief that will never be corrected by an error message. That is why the distinction is worth holding: the failure is silent. ## What it answers, and what it does not **It answers exactly one question:** has this launch had clusters generated, and if so, when. That is genuinely useful. It tells you whether an empty cluster list means "clustering never ran here" or "clustering ran and found nothing worth grouping" -- two very different situations that look the same through the cluster endpoint alone. **It does not tell you:** - how many clusters were produced, or how big they were - which normalisation setting the generation used - whether the grouping was any good - anything about a *previous* generation, since the attribute is replaced rather than appended to For all of those you read the launch's cluster list itself, where each `ClusterInfoResource` carries `index`, `message` and `matchedTests`. ## Two behaviours worth knowing 1. **An incremental, item-scoped update does not restamp it.** The attribute marks a full generation for the launch. So a fresh timestamp means the launch's clusters were rebuilt, not merely touched. 2. **It is dropped when launches are merged.** A merged launch does not inherit a clustering timestamp from the launches that went into it, which is correct -- the merged launch has not itself been clustered, and carrying the old stamp across would assert something false about the new launch's clusters. ## How this shows up in practice The typical use is operational rather than analytical: a script or a dashboard wants to know which of a project's launches have been clustered before it goes looking for clusters, or an engineer wants to know whether the empty list in front of them is a gap in coverage or a genuine result. Reading the launch's own attributes answers that in one call; inferring it from an empty cluster list does not answer it at all. The interview value of the question is smaller than the operational value, but it is a clean test of whether someone distinguishes **configuration** from **recorded state**. Those are different kinds of thing that happen to share a naming convention here, and the person who has actually operated the feature will say so without prompting.

  • A launch's cluster list is empty. What does this attribute let you conclude that the list alone cannot?
    Whether generation ever ran. An empty list is ambiguous: it can mean the analyzer was never asked, or that it ran and grouped nothing worth returning. The attribute's presence and timestamp settle it in one read, which is why operational scripts check the launch before going looking for clusters.
  • Why is the attribute not carried over when two launches are merged?
    Because the merged launch has not itself been clustered. Inheriting a timestamp from a constituent launch would assert something false about the merged launch's clusters, and someone reading it would believe grouping had run over the combined set when it had not. It is dropped deliberately during the merge.
  • How can you tell this key from an actual ReportPortal server property?
    By where it is read. Server properties are configuration the process reads at start-up; this key is data the clustering pipeline writes onto a launch at runtime, so you read it from the launch. The shared prefix is a naming convention, not a category, and setting it in configuration fails silently.

saying these in an interview costs you the question

  • Setting it in a config file or environment variable
  • Calling it a ReportPortal server property
  • Expecting it to reveal how many clusters exist
  • Assuming it accumulates a history of runs