Release LoadGen Api, Appliance and MCP Server: 1.0.0.11951

Release LoadGen Api, Appliance and MCP Server: 1.0.0.11951

LoadGen General

  • No general changes in this release.

LoadGen Api

  • [#8934] Improved diagnostics for E2E Monitoring sessions that end TimedOut/Failed with zero measurements and "No data" freshness even though the Core Agent is online and the workload script runs to completion. The API now records, per session, whether the off-host Core Agent can reach the API to report its results and warns when it cannot, so the next failing run pinpoints the failing tier; the underlying issue remains under investigation and the targeted fix will follow.
  • [#8923] Fixed two SSO provisioning gaps when a username claim override (e.g. preferred_username) and an email claim are configured. A user provisioned through SSO had a blank Email field in My Profile: the email resolved from the identity provider is now seeded into the user's profile on first sign-in (an existing value is never overwritten, and a seeding hiccup never blocks the sign-in). And because the username is captured once at first sign-in and deliberately never re-derived, a later username-claim change could not be applied to existing users, so admins can now rename a user via the new admin-only POST /security/users/{username}/rename, which cascades the rename across role assignments, per-user preferences and sign-out state, and answers 409 when the target name already belongs to another user. A renamed user's open sessions become invalid and the user must sign in again.
  • [#8845] Improved Repositories Request Access (Master enrollment) when the entered Master API URL does not point at a Master appliance. The URL can now be verified upfront (the check deliberately exposes no repository details), so a URL pointing at a Local (non-Master) appliance is caught before enrollment is attempted. Additionally, when the Master rejects an enrollment with an empty response body (for example the per-IP rate limit answering 429), the alert now includes the underlying "HTTP <status> <reason>" instead of the unactionable "The Master appliance rejected the enrollment request."
  • [#8946] Service Levels datasources can now use the appliance's managed local PostgreSQL without manually copying the connection string from the Storage tab. When a datasource is saved with the new Use local PostgreSQL option and an empty connection string, the API resolves the full connection string server-side using the least-privilege application role, so the credential never travels through the browser; the stored entry remains encrypted and datasource reads echo only the saved choice, never the secret. The string is resolved at save time, so after rotating the PostgreSQL password simply re-save the datasource (the same behavior as a manually entered string). Saving answers 422 when local PostgreSQL has not been initialized yet.
  • [#8942] Fixed the New Load Profile wizard failing to save with "The Name field is required." (HTTP 400) whenever the schedule toggle in Step 5 was enabled — the inline schedule editor has no Name input, so the validation could never be satisfied. The schedule name is now optional and is filled in automatically with the owning profile's name, which also means inline-created schedules show a proper label instead of a blank one in the cross-profile Testing → Schedules grid.
  • [#8912] Fixed uptime alert emails arriving with a literal $Field token in the subject (e.g. "Alert: <profile> - $Field 0.00") while $AlertName and $Threshold were substituted correctly. The value was only published under a legacy token name when a real alert fired; $Field is now substituted for real alerts too, and the legacy $MatchedField token keeps working in existing custom templates.
  • [#8929] Fixed the Load Profile wizard not persisting the per-user User Type selection: after saving, reopening the profile showed "-- none --" again. The saved profile now stores the selection and returns it when the profile is loaded, so the wizard can restore it; profiles saved before this release simply load with no User Type until set again.
  • [#8930] Fixed Run Test aborting with "There are no LoadGen Agents mapped to the requested profile" even though the profile's Users & Agents step showed an active agent assigned. Agent assignments saved by the wizard are now propagated to the runtime agent mapping per agent type (Full/Core/VDI) on every save, and the save-time validation recognizes them — simply re-saving a previously affected profile repairs it.
  • [#8924] Fixed Permissions → Repositories "Remove Role Assignment" failing with "An error occurred (405). Please try again." and leaving the entry in place. The delete operation was missing for repository role assignments (the user equivalent already existed); DELETE /security/members/repos/{id} now removes the assignment, works in both Local and Master-proxy modes, and is idempotent.
  • [#8908] Investigated a licensed appliance landing on the full-screen "License Required" page ("The appliance setup period has expired. A valid LoadGen license is required to continue.") immediately after an upgrade: no licensing regression shipped in the upgrade window, and an in-place upgrade does not reset or re-evaluate the setup period on an already-licensed appliance. The one code-reachable cause is now hardened: a startup problem reading the appliance's persisted machine identity can no longer unbind an existing license. The API logs an actionable startup error instead, and the appliance self-heals once the read issue is fixed and the API restarts.
  • [#8835] Fixed the Retrieve Body button of the HTTP Body Regex uptime check failing with "The body probe request failed. Check the API connection and try again." (HTTP 405). The affected appliance build predates the body-probe feature, which ships from this release onward; after upgrading, Retrieve Body fills the sample response textarea and the inline regex tester reports matches as designed.
  • [#8552] Fixed Web/Core load tests finishing with an empty Results page on appliances where E2E monitoring had ever run. Monitoring and load-test result ingestion contended for the same Core Agent connection, so test results could be silently dropped once monitoring had run. Each result is now routed to its rightful owner, so stand-alone web tests, tests running concurrently with monitoring, and pure monitoring sessions all receive their data; rescued test packets are ingested under the active test run.
  • [#8905] Fixed a Core Agent staying on the blue Initializing badge indefinitely when its host was unreachable, with nothing visibly happening until the operator pressed Reset. The status check now waits briefly for the agent's dial-back and then reports the agent Offline instead of initializing forever. Agents assigned to an E2E monitoring profile are also pre-warmed shortly before each scheduled run, so after re-pointing a profile to a different agent a reachable agent comes online on its own — no manual Reset required.
  • [#8899] PowerShell Script uptime checks can now use the credentials configured in the wizard's Set up authentication step. Previously the script only received $CheckName, $Target, $TimeoutMs and the custom parameters, so a script doing remote authentication failed with null-credential errors despite Basic Auth being configured. The configured authentication is now injected as $Auth* variables matching the auth type — $AuthUsername/$AuthPassword (Basic/SQL), $AuthApiKeyName/$AuthApiKey/$AuthApiKeyInHeader (API key), $AuthBearerToken, $AuthTenantId/$AuthClientId/$AuthClientSecret/$AuthScope (service principal), $AuthFunctionKey, and $AuthCustomHeaders — with secret values delivered as SecureString so they cannot leak through casual output, and injected after custom parameters so a same-named parameter cannot shadow a credential. The PowerShell uptime-check guide now documents the credential variables, the PSCredential pattern, and remote-execution guidance.

LoadGen Appliance

  • [#8946] The Appliance Agent now provides the managed PostgreSQL connection details to the API directly, backing the Use local PostgreSQL option for Service Levels datasources. The exchange is strictly server-to-server: it is not reachable through the browser-facing appliance management surface, and the browser-facing PostgreSQL status endpoint continues to omit every password.
  • [#8842] Fixed the Services Configuration Wizard failing at the Apply step when the InfluxDB engine was already initialized but the appliance's saved InfluxDB configuration was missing — typical when an InfluxDB data volume survives an appliance re-image, after manual provisioning, or when the configuration file is lost. Instead of dead-ending with an internal error, the appliance now rebuilds its InfluxDB configuration automatically and lets the wizard complete. The InfluxDB Discovery action on the Services tab uses the same recovery, so it no longer dead-ends with "No saved admin token and could not recover one from InfluxDB…"; manually creating an All-Access token in the InfluxDB UI remains the documented last resort only when automatic recovery fails.
  • [#8935] Remediated the Linux kernel local privilege escalation vulnerability CVE-2026-46333 (Qualys QID 387392, Severity 4) found by authenticated vulnerability scans of the appliance. Fresh appliance images ship the patched kernel, and already-deployed appliances self-heal by upgrading the kernel packages once at the next agent restart. The appliance never reboots itself: it raises the /var/run/loadgen/reboot-required flag so operators can schedule the reboot without killing in-flight monitoring runs. Unattended security updates (Ubuntu security and packages.microsoft.com origins, automatic reboot disabled) are configured alongside, so future kernel advisories are absorbed without waiting for a new appliance build.
  • [#8936] Applied the Microsoft .NET Security Update for May 2026 (Qualys QID 92390, Severity 4): the appliance host's ASP.NET Core 8 runtime is upgraded from 8.0.26 to 8.0.27, both in fresh appliance images and through the same one-time self-heal on already-deployed appliances.
  • [#8937] Upgraded libgcrypt20 to remediate the Ubuntu security notification USN-8319-1 (Qualys QID 6035724, Severity 3). The package is upgraded explicitly at image build and during the agent self-heal instead of waiting for the next unattended-upgrade cycle, so the finding clears on the immediate next authenticated scan.
  • [#8938] Upgraded the vim packages (vim, vim-tiny, vim-common, vim-runtime, xxd) to remediate the Ubuntu security notification USN-8304-1 (Qualys QID 6035705, Severity 3), covering whichever vim variant the appliance has installed.
  • Appliance boot hardening. Fixed a class of boot failures where an appliance could drop into the initramfs shell with "ALERT! /dev/mapper/ubuntu--vg-ubuntu--lv does not exist" after a kernel update. The appliance now guarantees a bootable initramfs at kernel-install time instead of merely detecting a broken one: every kernel install validates the resulting boot image and repairs it automatically when it is incomplete. Fresh images ship with this safeguard baked in; already-deployed appliances converge automatically at the next agent restart, regenerating existing boot images where needed, and the operator runbook gains a recovery procedure for appliances already affected.

LoadGen MCP Server

  • No MCP Server changes in this release.
Was this article helpful?
0 out of 0 found this helpful