Release LoadGen Api, Appliance and MCP Server: 1.0.0.11924

LoadGen General

• No general changes in this release.

LoadGen Api

• [#8807] SessionSight Heatmaps now show the actual captured page behind the click/scroll heat overlay instead of a blank slate background that only revealed that a page was clicked, not where. The preview reuses the DOM snapshot SessionSight Replay already records per session (no new tracking, uploads, or storage) and is matched to the selected viewport using the most recent session that entered directly on that page, served through the existing authenticated replay payload endpoint. Pages that only have sessions arriving mid-visit via in-app navigation keep the plain background with a "preview unavailable" hint; the on-page rendering ships with the matching FrontEnd release.
• [#8816] On the Uptime dashboard, two visually identical Unhealthy check cards could disagree on the open-incident counter, one showing an open incident and the other none, with no indication why. The card's red verdict follows a rolling recent-failure window, while incidents only open when the check's configured failure mode (Immediate, Retry count, or Time window) triggers; on a flapping check every intermittent success auto-resolves the incident and resets the consecutive-failure counter, so the two can legitimately disagree. GET /uptime/analytics/metrics now reports the configured failure mode, its threshold, and the live consecutive-failure count for any check that is currently Unhealthy without an open incident, giving the dashboard the data to explain the gap; in every other state the new fields are omitted, so existing clients are unaffected.
• [#8817] Fixed open uptime incidents never being auto-resolved when a check recovered through the manual Trigger action rather than a scheduled probe: the dashboard showed the check Healthy while the incidents page kept an orphaned open incident with the original failure reason. A successful manual trigger now resolves the open incident exactly like a scheduled success does, including the live incident-resolved update for connected clients. Failure behavior is unchanged: manual triggers still never open incidents, and wizard test runs still cannot create or close incidents.
• [#8826] Fixed PowerShell uptime checks saved with Full language mode failing their first Test Request with "PowerShell error: Cannot invoke method. Method invocation is supported only on core types in this language mode." The test path shipped the script body to the executor without its declared language mode, so right after authoring (or after a worker restart) the script silently ran in Constrained Language Mode and method calls such as .ToString() or .Split() quietly produced empty values. Test Requests now carry the script's language mode together with its body, so Full-mode scripts execute in Full mode from the very first run; scheduled check executions are unchanged.
• [#8813] Fixed JsonPath assertions on array elements always failing in the uptime-check wizard: clicking Use next to an array element in the response-body inspector fills in a path like $.capabilities[0], but the next Test Request rejected it with "JSON path '$.capabilities[0]' not found in response" even though the value was plainly visible in the response tree. The response validator only understood dot-notation paths, so every array-indexed assertion the inspector ever generated failed. Array indices now resolve correctly, including nested paths such as $.data.items[1].name; plain dot paths behave exactly as before, and out-of-range or malformed indices still report a clean "not found" rather than an error.
• [#8710] Hardened SSO sign-in against incomplete identity-provider metadata: when an IdP's OIDC discovery document omitted its authorizationendpoint or tokenendpoint, clicking Sign in with SSO failed with a hard HTTP 500 on /security/sso/initiate/{provider}. Both the sign-in and callback flows now validate the discovery document up front and redirect to the login page with ssoerror=metadataunavailable instead, and the API log names the exact JSON key the provider omitted, so the IdP-side configuration can be pinpointed without another debugging round.

LoadGen Appliance

• [#8812] Fixed appliance version-update jobs on Infrastructure → Appliance → Jobs reporting Failed while the Docker tab simultaneously showed the new version as active. The update jobs rewrote the appliance's Docker Compose configuration before pulling the new image, and the per-service version cards read that configuration as ground truth, so a failed image pull or container recreate left the UI claiming a version that was not actually running. All three update jobs (API, MCP Server, and FrontEnd) now roll the configuration back whenever a later step fails, keeping the version cards in line with the running containers, and write an explicit warning to the job output if the rollback itself could not be completed. The MCP Server and FrontEnd update jobs also gained the image-already-present fallback that previously only the API update job had.

LoadGen MCP Server

• [#8816] The uptime analytics tools automatically pick up the new failure-mode hint fields (failure mode, threshold, and live consecutive-failure count) for checks that are Unhealthy without an open incident, so MCP clients see the same explanation the dashboard gets, with no MCP Server configuration change required.