Release LoadGen Api, Appliance and MCP Server: 1.0.0.11972

LoadGen General

• No general changes in this release.

LoadGen Api

• [#8950] The appliance management API now supports the safer two-phase Let's Encrypt activation: the SSL status response gains a letsEncryptIssuanceState field (NotApplicable / Pending / Issued) plus a letsEncryptCertIssued flag, and a new cutover action completes the switch to the issued certificate. This lets the HTTPS wizard keep the current certificate serving while DNS-01 validation is still in progress and only switch over once the new certificate actually exists; see the Appliance section for the underlying fix.
• Stale monitoring sessions no longer shown as Running. Fixed Monitoring → Active listing sessions as permanently "Running" with impossible elapsed times (up to ~78 days): sessions interrupted by a restart or shutdown were never moved to a terminal state and kept being returned by GET /v1/monitoring/sessions/active. A background watchdog now marks any session running longer than the allowed maximum (default 15 minutes, configurable) as TimedOut, and already-stuck sessions self-heal automatically on its first sweep after updating. The active-sessions endpoint also returns the documented lightweight summary shape (including measurementCount and hasScreenshots) instead of full session records.
• [#8955] Appliances holding a Master / Multi-Site (LG052) license could still be stuck in Local mode, with Sync → Repositories reporting "Not a Master appliance" and no way to activate Master mode short of redeploying. The new license-gated POST /config/sync-repositories/promote-master endpoint (used by the Promote to Master action on Infrastructure → Licensing) switches the appliance to Master mode: it is rejected without the LG052 license (403) or while the appliance is enrolled with a remote Master (409), is an idempotent no-op when already a Master, and otherwise persists the change and signals that a restart is required to finish the promotion. A symmetric demote-master endpoint refuses to demote while child repositories are still registered.
• [#8934] Fixed E2E Monitoring sessions executed by an off-host Core Agent consistently ending TimedOut/Failed with Measurements: 0 and "No data" freshness, later carrying "Session failed: Superseded by a newer session for the same agent/profile.", even though the agent was online and the script ran to completion. The API now advertises a results call-back address that is reachable from the agent, including after a restart, so the agent's completion call arrives. As an immediate workaround without updating, setting the LOADGENDIRECTORCALLBACK_IP environment variable on the API container pins the advertised call-back address explicitly.
• [#8966] Fixed SSO federated logout ending on the identity provider's "Bad Request: The request is otherwise malformed" page (observed with Authentik). The logout request now sends only the idtokenhint (without a postlogoutredirect_uri), so the provider session is terminated and the user lands on the provider's own signed-out page, with no per-deployment redirect-URI registration needed on the IdP.
• [#8923] Fixed the SSO provider Username claim setting never being re-applied to existing users (accounts kept the username captured on their first login, typically the email address, even with preferred_username configured) and the Email field in My Profile staying empty for users whose profile predated the email claim mapping. A new opt-in provider setting, ReconcileUsernameOnLogin (default off, settable through the provider configuration API), re-applies the configured username claim on every login and renames the account when it has changed; if the new name collides with another user, sign-in still succeeds under the existing name and an administrator can resolve it via POST /security/users/{username}/rename. The profile email is now also back-filled on login when it is blank, and an address the user set themselves is never overwritten.
• [#8899] Fixed credentials configured on a PowerShell Script uptime check not reaching the script: the wizard Test failed with "Exception calling '.ctor' … the value of argument password is null" because passwords and client secrets submitted by the wizard were dropped before they reached the check execution. Submitted credentials are now encrypted as soon as they enter the API (on create, update, and wizard Test), so $AuthPassword is populated and credential patterns such as building a PSCredential from $AuthUsername / $AuthPassword work, including in Test runs of not-yet-saved checks. Stored checks and all API responses carry encrypted credentials only; submitted secrets are never echoed back.

LoadGen Appliance

• [#8950] Fixed the HTTPS wizard leaving the appliance unreachable (browser error ERRSSLUNRECOGNIZEDNAMEALERT, Connection Lost) when enabling Let's Encrypt with DNS-01 / Cloudflare validation. The previously served custom certificate could be removed while DNS-01 issuance (which can take 30 seconds to 2 minutes) was still in progress, leaving the appliance with no certificate at all in the meantime. Enabling Let's Encrypt now keeps the existing certificate serving HTTPS through the entire validation window; the switch happens through a separate idempotent cutover step (POST /appliance/ssl/letsencrypt/cutover) that only clears the old certificate once the new one has actually been issued, and GET /appliance/ssl/status reports the issuance progress (NotApplicable / Pending / Issued). A premature cutover call, or a misconfigured DNS token that never issues, now simply leaves the previous certificate serving and the appliance reachable.

LoadGen MCP Server

• No MCP Server changes in this release.