Release LoadGen Api, Appliance and MCP Server: 1.0.0.11861
LoadGen General
- No general changes in this release.
LoadGen Api
- [#8552] Fixed off-host Core agents producing zero data in the testing datasource even though monitoring of the same agent worked. The callback IP that the API advertises to a Core agent during a load test is now resolved through the same shared callback-address resolver that monitoring already uses, so off-host Core agents successfully dial back to the API and SMD/DUAF rows land in the testing datasource as expected.
- [#8552] Added a watchdog on the Core agent results listener that logs a warning naming the execution ID and advertised callback IP when no inbound agent connection has arrived, so the same class of "no data returned" issue is now diagnosable directly from the API log.
- [#8552] Added a single-line execution summary at test stop (users with succeeded/failed/in-progress counts and channel-drop count), so a support bundle pulled within minutes of a failure captures it without requiring deeper inspection.
- [#8552] Added an optional
executionIdparameter to the recent-logs diagnostics endpoint that returns the slice of log lines covering the test window plus a short margin on each side, closing a blind spot where short rolling tails could miss the entire test window. - [#8567] Fixed the Home page "E2E monitoring" KPI card showing zeros while the monitoring cockpit page showed real numbers. The card previously had no backing API operation; its statistics are now composed from the same monitoring data the cockpit page uses, so the Home card matches the cockpit for the same time window. The statistics degrade gracefully (returning zeros) when no monitoring datasource is configured or the datasource is unreachable, so the Home page stays sub-second.
- [#8549] Fixed appliance debug log download links returning "No webpage was found" in the browser. The API now generates the download URLs through the routing system instead of by hand, so they correctly include the version prefix and stay correct if the prefix changes in a future release. Backup downloads, which were never affected, are unchanged.
- [Monitoring] Hardened the new monitoring agent address resolution so it short-circuits DNS when the configured address is already a valid IP literal, preventing corporate DNS wildcards from returning the wrong host. Monitoring also now backfills the agent's IP from the Core/Full agent registry when the assignment record itself does not carry one, so monitoring picks up the same address the load-testing and online-check paths already use successfully.
- Fixed zombie reconnect loops in the load-bot agent transport after an agent host was replaced or a monitoring session was force-disconnected. The transport now spawns the reconnect loop only when auto-reconnect was opted into, and force-disconnect now also cancels any in-flight reconnect work so it cannot undo the teardown.
LoadGen Appliance
- [#8577] Added support for uploading a password-protected (encrypted) private key in the SSL wizard's custom certificate flow. The upload endpoint now accepts an optional passphrase, detects PKCS#8 and legacy PEM encrypted keys, and decrypts the key on the appliance using the passphrase before activation. The passphrase is never exposed via command-line arguments, environment variables, or persisted state, and a typed
ENCRYPTEDKEYPASSPHRASE_REQUIREDresponse code replaces the previous misleading "Certificate and private key do not match" error so the wizard can prompt the operator unambiguously. Existing callers that upload an unencrypted key are unaffected. - [#8576] Added DNS-01 challenge support for Let's Encrypt certificate issuance alongside the existing HTTP-01 path. This enables certificates for hosts that aren't reachable from the public Internet on port 80, environments where inbound port 80 is blocked, and wildcard certificates which HTTP-01 cannot issue at all. Cloudflare and AWS Route53 are supported in this first release; the wizard lists the supported providers and the credential fields each one requires. DNS provider credentials are stored in a separate file with restrictive permissions and never enter the Docker
.env. HTTP-01 deployments keep working unchanged after upgrade. - [#8570] Added
GET /appliance/network/pendingto recover the in-flight confirmation token after an appliance IP change. Without this, a browser circuit that reconnected on the newly-applied IP had no way to learn the token, and the agent always rolled back even though the operator was on the new address. Any HTTP client (including a fresh browser circuit on the new IP) can now fetch the pending token, requested address and gateway, total rollback seconds, and remaining seconds, and confirm the change before the 60-second auto-rollback fires. Pending state remains in-memory only — an agent restart inside the rollback window still cancels the change. - Fixed the SSL / multi-domain wizard accepting
apiDomainandmcpDomainvalues, which corrupted the reverse-proxy routing on existing appliances and could break the GUI. Those fields have been removed from the wire contract; the API now rejects requests that include them, and a startup repair pass automatically restores correct routing on appliances that were already affected. Neither the API nor the MCP service needs its own FQDN. - [#8484] Re-verified end-to-end that the SSL Certificate Status panel populates correctly on an up-to-date appliance — Mode, Subject, Issuer, ValidFrom, ExpiresAt, DaysUntilExpiry, and IsExpired all populate per row for self-signed PEMs. No source change in this release; the rejection that triggered the re-verification was reproduced against an older agent build, so the action is to redeploy the appliance agent on affected systems.
LoadGen MCP Server
- No MCP Server changes in this release.