Release LoadGen Api, Appliance and MCP Server: 1.0.0.11949

LoadGen General

• Reliability hardening across all components. A product-wide audit of the API, its background workers, the Appliance Agent, and the MCP Server closed seven gaps that could affect recently introduced features. The SSO logout-behavior setting, the MCP Server version reported through diagnostics, the appliance debug-logging state, and the Uptime wizard's Azure resource picker now behave reliably; there are no functional changes otherwise.

LoadGen Api

• [#8867] Fixed SSO-provisioned users being denied with HTTP 403 MEMBERNOTFOUND on virtually every page and endpoint, even when their IdP group mapped them to the Admin role: externally provisioned accounts were never registered with the permission system. SSO logins now create the matching permission membership, backed by two new built-in roles (Ops and User) alongside the existing admin role, and IdP group changes are re-applied on every login instead of being frozen at first sign-in. SSO users now also appear in the Permissions tab, and deleting one there actually prevents silent re-provisioning on the next login (a deleted user can be explicitly unblocked when access should be restored). Also resolves [#8869] and [#8862], which shared the same root cause.
• [#8895] Added configurable federated sign-out for SSO providers. Previously, signing out of LoadGen only cleared the local session; the IdP session (for example Authentik) stayed alive, so other IdP-protected apps remained accessible without re-authentication. Each SSO provider now has a logout behavior setting (LoadGen only or Federated) plus an optional logout URL; when federated, sign-out hands the browser a fully assembled IdP end-session URL (discovered automatically from the IdP when no explicit URL is configured), and the link survives token refresh. If no end-session URL can be resolved, sign-out safely degrades to LoadGen-only instead of stranding the user.
• [#8866] Added configurable claim mapping for OIDC SSO providers: optional Username claim, Display name claim, and Email claim settings let operators point LoadGen at the exact IdP claims to use (for example preferred_username or upn), instead of having to reshape the IdP's scope mapping to match LoadGen's defaults. When a configured claim is absent from a login, LoadGen falls back to the standard claim chain so a typo cannot lock anyone out, and the SSO audit trace records which claim produced each identity attribute. Existing providers keep today's behavior until the new fields are set.
• [#8904] Fixed the E2E Monitoring profile wizard losing the alert profile selected in Step 9 (Alerting): after saving and reopening the profile, the picker silently reverted to "None (No alerts)" because the selection was never persisted. Monitoring profiles now store their linked alert profiles, and alert evaluation combines profile-linked and schedule-linked alert profiles into one set. Existing profiles without explicit links behave exactly as before.
• [#8880] Fixed failed E2E Monitoring sessions showing an inconsistent mix of Failed and Cancelled rows when a new scheduled session superseded one that was still running. Both supersede paths now record the same Failed result with the message "Session failed: Superseded by a newer session for the same agent/profile.", and genuine shutdown cancellations still record Cancelled.
• [#8823] Fixed uptime alert profiles configured with a trigger but an empty Threshold Expression never sending a notification: an empty expression evaluated to "never fire", so operators expecting "email on any failure" received nothing. An empty-expression profile that is explicitly linked to an uptime check now defaults to the canonical success equals 0 condition (fire on any failed check). The fallback behavior for checks without explicitly linked profiles is deliberately unchanged, so existing installations see no new alarm storms.
• [#8835] The HTTP Body Regex uptime wizard's "Retrieve Body" button is now wired end-to-end: it fetches the live response body of the candidate endpoint and drops it into the Test pattern field, eliminating the DevTools/Postman/curl round-trip. Very large bodies are truncated with an explicit indicator, the response charset is honored (with a clear error instead of garbled text when a body cannot be decoded), and transport failures return the same descriptive messages as the existing header probe.
• [#8851] API Testing Run History now supports deleting individual run entries: a new DELETE /api-testing/runs/{runId} endpoint removes the run record together with its artifacts, events, and per-node telemetry. Runs that are still queued, running, or paused are refused with HTTP 409 and must be cancelled first, matching the existing safety posture.
• [#8850] API Testing retention settings can now be changed at runtime instead of being fixed at startup, via the new retention link on the Run History page and the API Testing section in Settings. Changes take effect immediately, even shortening a cleanup interval mid-wait, and the settings persist across restarts.
• [#8856] API Flows can now be scheduled. A complete scheduling surface at /api-testing/schedules supports cron-based schedules with time-zone support, enable/disable toggling, a manual "run now", and per-schedule status of the last fired run; invalid cron expressions are rejected with a clear validation error. A flow that only has an uncommitted draft is skipped with the status "Skipped: flow has no committed revision (Draft)" instead of failing silently, and deleting a flow automatically cleans up its schedules.
• SessionSight visitor identity stitching. The SessionSight tracker gains an identify() call that links the anonymous visitor id to your own user id, persisted for a year in a first-party cookie with optional cross-subdomain support, so sessions of the same person, even across devices, can be tied together; Google Ads click ids (gclid) are captured alongside for future attribution. A new GET /results/{datasource}/sessionsight/identities/{externalId} endpoint returns the stitched profile: first and last seen, linked visitor count, total events, and a per-visitor breakdown. Identity data follows the same retention and container-purge rules as all other SessionSight data.
• Load profile filtering by technology. GET /v1/config/load-profiles accepts a new optional, case-insensitive, comma-separated ?technology= query parameter (for example ?technology=web,core) so clients such as Studio Light can request only the load profile types they support instead of discarding rows in the browser. Unknown values are ignored rather than rejected, and omitting the parameter keeps today's behavior unchanged.
• [#8896] Fixed the Home setup checklist reappearing on every login even when "Don't show again on this browser" was checked: the dismissal was stored only in browser storage, which not every browser reliably persists. The dismissal is now stored per user on the appliance, and user-preference updates perform a partial merge, so updating one preference can no longer wipe another (for example, dismissing the checklist no longer risks clearing a saved support email address). The checklist can still be brought back on demand via an explicit un-dismiss.
• [#8906] Fixed the Home setup checklist marking steps as Configured that were never completed on a freshly deployed appliance: a deployment-assigned hostname made Step 1 "Set hostname" look configured, and plain DHCP made Step 2 "Configure IP / DNS" look configured. Step 1 now tracks an explicit per-account "hostname configured" flag that is set when the admin actually saves a hostname. Existing installations with a custom hostname will show Step 1 as not configured until the hostname is saved once more; a single re-save heals it, and the card remains dismissable.
• [#8845] Fixed Repositories → Request Access failing whenever the Master API URL pointed to a remote Master: the enrollment request was always sent to the local appliance itself, which rejected it with "This endpoint is only available on the Master API." The request is now forwarded server-side to the Master URL you actually typed, and failures come back as clear, structured reasons instead of raw JSON: invalid URL, URL points to a non-Master appliance, the Master rejected the request (including the Master's own message), or the Master is unreachable.
• Automated test reliability. Improved the reliability of an internal Uptime check that could behave inconsistently depending on the time of day. No product behavior changed.

LoadGen Appliance

• [#8848] Fixed Connect to Remote API being unable to sign in to a remote appliance: the sign-in endpoint was not exposed through the appliance's reverse proxy on HTTPS (443), while the connection dialog suggested a URL that is only reachable inside the appliance. A new idempotent reverse-proxy migration adds narrow, exact-match routes for /security/login and /security/refresh only, so cross-appliance sign-in and token refresh work over 443 while all administrative endpoints under /security/ remain internal-only. Existing appliances self-heal automatically on the next agent restart, with configuration validation and rollback if the new rules fail to load.
• [#8842] Fixed the Services Configuration Wizard showing a developer-oriented error that named an internal REST endpoint when settings were applied while InfluxDB was still starting. The message now reads "InfluxDB container is not running yet. Enable the service from the Services tab and wait for the container to start before retrying."

LoadGen MCP Server

• [#8856] Added full MCP support for the new API Flow scheduling feature: seven new tools (listapiflowschedules, getapiflowschedule, createapiflowschedule, updateapiflowschedule, deleteapiflowschedule, toggleapiflowschedule, and runapiflowschedulenow) let AI assistants manage flow schedules the same way they already manage monitoring schedules.