Skip to main content

Retries reporting

Some frameworks allow to retry Test execution according to provided conditions (TestNG) or just retry it predefined number of times. First execution is a simple TestItem and next ones are called Retries. In ReportPortal these items are grouped and displayed as a sequence of executions for the same Test:

When you click on the retries link you can switch between Retries and see their logs:

On the Log view you can also switch between Retries:

Retries reporting

Common child Test item request (check reporting dev guide) looks like:

curl --header "Content-Type: application/json" \
--header "Authorization: Bearer 039eda00-b397-4a6b-bab1-b1a9a90376d1" \
--request POST \
--data '{"name":"example step","startTime":"1574423237000","type":"step","launchUuid":"<launch uuid>","description":"Item that should be retried"}' \
http://rp.com/api/v1/rp_project/item/<parent uuid>

With body:

{
"name": "example step",
"startTime": "1574423237000",
"type": "step",
"launchUuid": "<launch uuid>",
"description": "Item that should be retried"
}

And response:

{
"id": "uuid-of-the-first-step"
}

Request for a retry looks the same, but has field retry=true:

{
"name": "example step",
"startTime": "1574423237100",
"type": "step",
"launchUuid": "<launch uuid>",
"description": "Item that should be retried",
"retry": true
}

To be displayed as a retry reported Test item should have the same name, parentUuid, launchUuid and uniqueId (if you provided it explicitly). If one of mentioned fields is not matched (for example Test item with the same name but different uniqueId and vise versa) Test items won't be grouped as retries. Also Test item with type Suite cannot be reported as a retry.

Retries handling triggered only if Test item has retry=true flag in the request. For example:

First request will trigger retries handling, but if it's the first reported Test item it won't be a retry:

{
"name": "example step",
"startTime": "1574423237100",
"type": "step",
"launchUuid": "<launch uuid>",
"description": "Item that should be retried",
"retry": true
}

Second request won't trigger retries handling, because retry=false is specified (or this field isn't provided) in the request:

{
"name": "example step",
"startTime": "1574423237100",
"type": "step",
"launchUuid": "<launch uuid>",
"description": "Item that should be retried",
"retry": false
}

As a result 2 separate Test items will be displayed, so ORDER of sent requests matters (if send this items in reversed order they will be grouped as retries).

In ReportPortal the only Test item from the Retries group that has statistics and can have an issue attached is the one with max startTime. In previous requests startTime was 1574423237000 for the first one and 1574423237100 for the second one, so the second one is a 'main' Test Item with statistics and issue (if attached).