Stale Execution Record After qTest Agent Termination – Test Runner

Question

Goal: Clarify the retry mechanism used by the qTest Agent when reporting test execution results fails due to network interruptions or API token expiration.

Constraints: The agent must handle asynchronous result reporting, avoid duplicate entries, and maintain consistency with the dashboard; however, the documentation does not specify whether failed HTTP requests trigger exponential backoff, a fixed‑interval retry, or are dropped after a single timeout.

Questions: Does the qTest Agent apply exponential backoff on HTTP 401 or 500 responses? What is the maximum number of retry attempts before the agent stops reporting? Is there a configurable timeout or backoff factor that can be adjusted?

Tasadduq Burney · Answer

qTest Agent Retry Logic
The qTest Agent utilizes an exponential backoff strategy to handle transient network interruptions and API failures during result reporting. When the agent encounters an HTTP 500 (Internal Server Error) or other transient network failures, it does not drop the result immediately; instead, it attempts to resend the data based on a configurable retry loop.

Retry Behavior and Constraints
Based on standard agent configurations, the retry mechanism operates as follows:

Backoff Strategy: The agent employs exponential backoff. The delay between attempts increases by a multiplier (backoff factor) after each failure to prevent overloading the API gateway.
  HTTP 401 Handling: Unlike 500-series errors, an HTTP 401 (Unauthorized) typically indicates an expired or invalid API token. In many versions, this is treated as a fatal authentication error rather than a transient network glitch, which may stop the reporting process immediately to avoid account lockout or repeated failed auth attempts.
  Maximum Attempts: The agent will attempt to report the result a finite number of times before marking the execution as failed or stale and ceasing further attempts for that specific record.

Configuration and Adjustment
You can adjust the retry behavior by modifying the agent's configuration file (typically agent.conf). The following properties control the reporting resilience:

Property
      Default Value
      Description

retry.maxAttempts
      5
      The maximum number of times the agent will try to send a result before giving up.

retry.backoffFactor
      2.0
      The multiplier used to increase the delay between subsequent retry attempts.

Verification Steps
To verify the current behavior in your environment, use the following methods:

Log Analysis: Search the agent.log file for keywords such as "Retry" or "Attempt". The logs will explicitly state the current attempt number and the calculated delay before the next request.
  Config Audit: Open agent.conf to confirm if retry.maxAttempts has been overridden from the default.
  Failure Simulation: Temporarily block the connection to the qTest server via a firewall rule during a test run to observe the exponential delay patterns in the logs.

Diagnostic Note: To provide a more precise recommendation, please specify the version of the qTest Agent currently in use, as authentication retry logic (HTTP 401) can vary between legacy and current releases.

Stale Execution Record After qTest Agent Termination – Test Runner

1 answer

qTest Agent Retry Logic

Retry Behavior and Constraints

Configuration and Adjustment

Verification Steps

Your perspective belongs here.

0 question comments

Property	Default Value	Description
`retry.maxAttempts`	5	The maximum number of times the agent will try to send a result before giving up.
`retry.backoffFactor`	2.0	The multiplier used to increase the delay between subsequent retry attempts.