Workable.SqlServer 1.1.83126.1

• net10.0

  • Microsoft.Data.SqlClient (>= 6.1.3)
  • Microsoft.Extensions.DependencyInjection.Abstractions (>= 10.0.0)
  • Workable.Abstractions (>= 1.1.83126.1)

# 1.1.083126.1

Date: 2026-08-31

These notes describe only the user-visible, operational, and public API differences from `1.1.082326.1`. Intermediate implementation details are omitted.

## Breaking Changes

- There are no intentional breaking API changes in this release. The diagnostics health API is additive: existing `IWorkSystemDiagnostics` implementations default to `NotConfigured`, and the existing positional `WorkableHttpSystemDiagnostics` constructor remains valid.

## Execution Diagnostics and SQL Server Startup

- A persistent execution-diagnostics repository that fails during initialization no longer brings down its Workable system or the application host. Work execution continues without persisted execution logs or profiles for that system until the process restarts.
- Initialization failure emits the prominent `Error`-level event `ExecutionDiagnosticsInitializationFailed`, including the provider exception in server logs and an explicit warning that evidence will not be persisted. Cancellation, out-of-memory, and stack-overflow failures retain their existing propagation behavior.
- Added `IWorkSystemDiagnostics.ExecutionDiagnosticsPersistence` with `NotConfigured`, `PendingInitialization`, `Healthy`, and `Unhealthy` states, `InitializationFailedAt`, `PersistenceAvailable`, and `IsHealthy`. Authorized HTTP system diagnostics expose the same health state without exposing provider or connection details.
- System capabilities now report execution-diagnostics persistence as unavailable after initialization fails. New sessions receive the updated capability, evidence reads return no persisted results, and capture-rule mutations remain unavailable while the system is unhealthy.
- `Workable.SqlServer` now coordinates schema work through one host-scoped initializer. One completed schema-deployment result is reused per application host, and queue, workflow, and execution-diagnostics schema validation runs at most once after success for each component used by that host, even when many Workable systems start together. Canceled initialization remains immediately retryable.
- Successful deployment and validation results are reused. A component failure is shared across the other systems encountering that startup failure, preventing them from repeatedly starting LocalDB, reconnecting to an unavailable server, or attempting the same deployment. A repeated initialization for the same system retries, and a diagnostics deployment failure does not suppress the first durable queue or workflow deployment attempt.
- When durable-queue and explicit diagnostics-persistence registrations use different `AutoDeploySchema` values, automatic deployment is enabled if either registration enables it. Conflicting connection or schema registrations continue to fail validation.
- Only execution-diagnostics repository initialization adopts the new fail-open behavior. Durable queue and workflow persistence retain their existing startup, store-unavailable, and retry semantics.

## Admin UI Authentication and Transport Security

- Delegated Entra access tokens now stay out of browser cookies and Web Storage. They use a bounded 256-entry, exact-scope, rotation-aware per-process cache with a 64 KiB per-token limit and a 24-hour maximum accepted lifetime; cache eviction or process restart falls back to the encrypted browser-held refresh authority.
- Encrypted refresh snapshots are versioned, immutable, bound to the signed-in identity, session, client, and complete target configuration, and limited to a 6 KiB request-cookie budget with a 4 KiB refresh-token limit. A newer browser rotation invalidates stale process-local access-token entries.
- Logout clears the signed-in session's local access-token cache and prevents an in-flight refresh from repopulating it. Concurrent refreshes remain coordinated per signed session, and reverse-order responses cannot replace newer refresh authority.
- Unsupported and pre-v1 delegated-token snapshots are rejected and cleared. The admin UI sends the browser through sign-in again instead of leaving the current page in a repeated authorization failure.
- Oversized local admin-session headers now open a page-wide request circuit breaker. HTTP polling, queries, token acquisition, SignalR reconnects, and fallback restarts stop instead of sustaining a `431 Request Header Fields Too Large` retry loop, and the UI tells the operator to clear site data and sign in again.
- A `431` returned by the hosted Workable API is marked as an upstream response and remains isolated to that request; it does not disable unrelated admin UI requests.
- The checked-in `npm run dev` and `npm start` commands launch Node with a 32 KiB maximum HTTP header size. This bounds normal self-hosted deployments while allowing the compact session and refresh cookies used by the UI.

## Admin Console Reliability and Usability

- Infinite worker, iteration, catalog, log, timeline, and message pagination stops after a terminal page failure instead of retrying from scroll or render loops. An explicit refresh, query change, or scope change starts a new attempt.
- Switching API hosts, systems, definitions, workers, or iterations clears stale scoped data. Results from superseded in-flight pagination requests are ignored, and catalog failures reset correctly when moving to another scope.
- Worker detail now keeps the latest iteration's execution-failure banner visible even when a recurring worker has already returned to `Waiting`. The banner is keyed to the failed iteration so dismissing one failure does not hide a later failure.
- Active as well as completed iteration rows can open iteration detail, allowing operators to inspect an execution while it is still running.
- Realtime worker-overview log and timeline payloads now contain the latest 50 matching entries in the requested sort direction. Ascending views no longer receive the oldest matching entries.
- Scrollbar styling now applies consistently to the full admin UI instead of only selected data grids.

## Worker and Sample Host Fixes

- Worker-start transitions are now published before executor launch. Fast work can no longer complete before observers receive its start event.
- Fast non-durable workflow children now retain their completion receipt when execution finishes before the dispatch step records the child worker id. Automatic worker retention can no longer remove that evidence and leave a join or operator view without the child's final state.
- Restored the sample host's fake authentication as a real ASP.NET Core authentication scheme and middleware pipeline, so its documented authorization profiles work with the host-owned authentication model introduced in `1.1.082326.1`.

## Performance

- Against the pre-change implementation with the SQL schema already installed, startup for 8 systems improved from 225.88 ms to 133.39 ms (41.0% faster), and startup for 32 systems improved from 870.75 ms to 430.24 ms (50.6% faster). Allocation for the 32-system case fell from 8,730.37 KB to 3,392.41 KB (61.1% lower). The one-system case remained within run variance.
- Against one intentionally unavailable diagnostics database, the final startup rerun measured 10.14 ms, 10.59 ms, and 11.25 ms for 1, 8, and 32 systems. The nearly flat curve confirms that later systems reuse the first component failure instead of repeating the connection attempt, while preserving same-system and durable-component retries.
- Diagnostics health reads now reuse immutable snapshots and allocate 0 B for not-configured, healthy, unhealthy, and session-projected states. Session creation measured 49.31 ns / 456 B when healthy and 49.91 ns / 456 B when unhealthy, with no measurable regression from dynamic capability reporting.
- An authorized `GET /workable/diagnostics` request measured 19.21 microseconds / 24.2 KB end to end after extended warmup. Installed-schema and unavailable-database reruns remained within the preceding post-change variance.
- Two focused post-fix workflow benchmark runs measured 65.87-70.65 microseconds and 69.0-69.3 KB allocated per completed single-dispatch workflow; the pending-receipt safeguard did not introduce an anomalous hot-path cost.

## Deployment Notes

- No SQL schema migration is introduced by this release. The SQL change coordinates existing deployment and validation work at host scope.
- A diagnostics initialization failure remains unhealthy for the lifetime of the process. Correct the provider, permissions, schema, or connection problem and restart the application to re-enable persistence.
- Existing delegated Entra cookie state from before the new snapshot version is intentionally not migrated; affected administrators sign in again once after deployment.
- Deployments that bypass the checked-in Node scripts should pass `--max-http-header-size=32768` themselves and configure the trusted reverse proxy or load balancer with a compatible limit.

## Documentation and Testing

- Updated diagnostics, public API surface, SQL Server persistence, Entra authentication, realtime, sample-host, and admin UI documentation for the final behavior and operational recovery steps.
- Added focused schema-startup, unavailable-database, diagnostics-health, and authorized HTTP benchmarks, including retained before/after results in the performance harness.
- Added regression coverage for diagnostics fail-open behavior and health authorization, shared SQL initialization and failure reuse, Entra snapshot bounds and recovery races, `431` retry suppression, pagination terminal failures and stale-response races, active-iteration navigation, realtime failure presentation, sample authentication, worker-start event ordering, and fast workflow-child finalization.
- Repository CI now validates the admin UI on Node 24 with install, tests, changed-code coverage, and the Next.js production build in addition to the .NET validation surfaces.