Workable.SignalR
1.1.80726.1
See the version list below for details.
dotnet add package Workable.SignalR --version 1.1.80726.1
NuGet\Install-Package Workable.SignalR -Version 1.1.80726.1
<PackageReference Include="Workable.SignalR" Version="1.1.80726.1" />
<PackageVersion Include="Workable.SignalR" Version="1.1.80726.1" />
<PackageReference Include="Workable.SignalR" />
paket add Workable.SignalR --version 1.1.80726.1
#r "nuget: Workable.SignalR, 1.1.80726.1"
#:package Workable.SignalR@1.1.80726.1
#addin nuget:?package=Workable.SignalR&version=1.1.80726.1
#tool nuget:?package=Workable.SignalR&version=1.1.80726.1
Workable
Workable is a .NET work orchestration library for applications that need more than "run this in the background." It turns background jobs, operational tasks, recurring work, and user-triggered actions into first-class work the host can queue, observe, control, and configure.
Most applications eventually grow work that does not fit cleanly inside the request, controller action, message handler, or command that started it. Sending email, refreshing caches, synchronizing data, running maintenance tasks, retrying transient failures, and coordinating long-running operations all need identity, state, cancellation, status, events, and a way to be found later. Workable gives that work a consistent runtime model instead of leaving each feature to invent its own.
Workable is useful when you want feature code to define work near the feature that needs it, while the host application keeps control of execution. Feature assemblies can declare their own work with Workable.Sdk. Libraries that need to use a hosted system can depend on Workable.Abstractions and accept IWorkSystem from the host. The host application owns the actual Workable systems, decides which work belongs in each system, and controls how workers start, retry, recur, respect concurrency, and stay available for inspection.
That split lets teams add work near the feature that needs it without forcing every feature library to know how the application hosts work. At runtime, the host gets a consistent surface for queueing work, awaiting completion, pausing, canceling, reconfiguring workers, and subscribing to work events.
Workable also gives applications a path to expose the same authored work through more than one channel. Direct .NET callers, HTTP endpoints, MCP clients, and realtime SignalR clients can all work against the same catalog while preserving request context, structured outcomes, worker history, and invocation rules.
Why Use Workable?
- Define work once and invoke it through .NET, HTTP, or MCP when those channels are enabled.
- Register workflow definitions that coordinate existing work through dispatch, typed fan-out, parallel branches, and join steps inside the host runtime.
- Keep feature libraries independent from the host runtime while still letting them contribute work.
- Queue fire-and-forget work without losing the ability to query, observe, cancel, pause, retry, or purge it.
- Give operators a real admin surface for work: live system and worker visibility, executable definitions, diagnostics, and control actions instead of one-off job screens and custom tooling.
- Attach runtime behavior such as recurrence, transient retry, failed-worker handling, idempotency, concurrency, durability, retention, logging, profiling, initialization, invocation policy, and start policy.
- Use structured inputs, outputs, messages, worker snapshots, event payloads, and status summaries instead of ad hoc task tracking.
- Preserve who or what started work through request context and origin metadata for HTTP, MCP, SignalR, and direct .NET calls.
Packages
Core Packages
Workable.Sdk: contracts and registration helpers for assemblies that author work.Workable.Abstractions: contracts for libraries that consume an already-hosted work system.Workable: in-process host and runtime for Workable systems.
Optional Packages
Workable.SqlServer: SQL Server persistence integration for durable queueing and completion, durable workflows, persistence-backed idempotency, and persistence-backed concurrency.Workable.AspNetCore: ASP.NET Core request-context and authorization integration for custom endpoints and hosts.Workable.Entra: Microsoft Entra ID bearer-token validation and Workable authorization claim mapping for ASP.NET Core target apps.Workable.Views: shared component-view contracts and projections used by HTTP and SignalR adapters; most applications receive it transitively throughWorkable.HttpApiorWorkable.SignalRinstead of referencing it directly.Workable.HttpApi: standard HTTP endpoints for queueing, querying, and controlling workers and workflow runs.Workable.Mcp: MCP server adapter for authored work, worker and workflow queries, and worker and workflow actions.Workable.SignalR: realtime worker collections, worker and workflow events, worker details, and component-view updates for ASP.NET Core clients.
Apps And Tools
apps/samples/Workable.SampleHost: runnable ASP.NET Core sample app with HTTP API, MCP, SignalR, fake-auth profiles, and SQL Server LocalDB durability scenarios.apps/tools/Workable.PerformanceHarness: opt-in scenario runner and BenchmarkDotNet harness for runtime, query, view, realtime, and SQL durability performance work.apps/tools/Workable.SqlServer.Cli: SQL Server schema generation and deployment CLI for Workable persistence.apps/web/workable-admin-ui: Next.js admin UI for inspecting and operating Workable systems through the HTTP API and SignalR realtime updates.
Documentation
Start with the docs landing page: Workable Docs.
Recommended entry points:
- Getting Started if you are evaluating or integrating Workable.
- Registration if you are authoring work in feature assemblies.
- Workflows if you want to author multi-step orchestrations from existing work definitions.
- Implementation if you want to implement work classes and understand what executor code can do at runtime.
- Queueing if you already have work definitions and want to invoke them.
- Configuration if you are tuning start behavior, retry, recurrence, failed-worker handling, concurrency, durability, logging, retention, or invocation rules.
- HTTP API, MCP, and Realtime if you are exposing Workable over transports.
- Abstractions Surface if you are consuming a hosted system from another library.
- Workable SQL Server Integration if you need durable queueing, durable workflows, or persistence-backed coordination.
- Sample Host if you want a runnable reference app.
- Admin UI if you want the browser-based operator surface.
- Performance Harness if you are measuring runtime or adapter performance.
| Product | Versions Compatible and additional computed target framework versions. |
|---|---|
| .NET | net10.0 is compatible. net10.0-android was computed. net10.0-browser was computed. net10.0-ios was computed. net10.0-maccatalyst was computed. net10.0-macos was computed. net10.0-tvos was computed. net10.0-windows was computed. |
-
net10.0
- Workable (>= 1.1.80726.1)
- Workable.Abstractions (>= 1.1.80726.1)
- Workable.AspNetCore (>= 1.1.80726.1)
- Workable.Views (>= 1.1.80726.1)
NuGet packages (1)
Showing the top 1 NuGet packages that depend on Workable.SignalR:
| Package | Downloads |
|---|---|
|
Workable.HttpApi
Expose standard ASP.NET Core HTTP endpoints for queueing Workable definitions, querying workers, and sending worker actions. |
GitHub repositories
This package is not used by any popular GitHub repositories.
| Version | Downloads | Last Updated |
|---|---|---|
| 1.1.83126.1 | 151 | 9/1/2026 |
| 1.1.82326.1 | 337 | 8/24/2026 |
| 1.1.81126.1 | 165 | 8/11/2026 |
| 1.1.80926.1 | 107 | 8/9/2026 |
| 1.1.80726.1 | 119 | 8/8/2026 |
| 1.1.80526.1 | 132 | 8/5/2026 |
| 1.1.71926.1 | 138 | 7/21/2026 |
| 1.1.70926.1 | 155 | 7/10/2026 |
| 1.1.70626.2 | 203 | 7/6/2026 |
| 1.1.70626.1 | 137 | 7/6/2026 |
| 1.1.63026.1 | 127 | 6/30/2026 |
| 1.1.61226.1 | 140 | 6/12/2026 |
| 1.1.159.1 | 145 | 6/8/2026 |
| 1.1.158.1 | 131 | 6/7/2026 |
| 1.1.157 | 134 | 6/7/2026 |
| 1.1.153.1 | 139 | 6/2/2026 |
| 1.1.146.1 | 297 | 5/26/2026 |
| 1.1.142.3 | 140 | 5/23/2026 |
| 1.1.0 | 135 | 5/22/2026 |
| 1.0.0 | 135 | 5/21/2026 |
# 1.1.080726.1
Date: 2026-08-07
## Breaking Changes
- `IWorkAuthorizationGroupProvider.GetGroups(...)` is now asynchronous and accepts a `CancellationToken`. Custom providers must return `ValueTask<IReadOnlySet<string>>` and observe cancellation.
- `IWorkSystem.CreateSession(...)` and `IWorkSystem.DescribeAccess(...)` now return `ValueTask` results because authorization-group resolution may require asynchronous I/O. Their existing unsuffixed names are retained.
- `IWorkQueueService` now requires `NotifyDurableWorkAvailable()`. Custom queue implementations, decorators, and test doubles must implement the new synchronous notification member. This source break is intentional; no default compatibility implementation is provided.
## Added
- Added `IWorkAuthorizationGroupContextProvider` and `IWorkAuthorizationGroupResolver` so invocation adapters can contribute ambient authorization groups while durable and background execution resolves groups for a persisted actor through `IWorkAuthorizationGroupProvider`.
- Added `IWorkQueueService.NotifyDurableWorkAvailable()` so applications using caller-owned durability transactions can wake the local durable queue reader immediately after a successful commit.
- Added durable lifecycle benchmark coverage for caller-owned SQL transaction commit, notification, and completion.
- Added originating-actor criteria, an actor index, and actor-keyed change notifications for worker queries and realtime invalidation, including HTTP query support.
- Added `WatchWorkers` as the discoverable worker-list form of the existing named workers view, plus `WatchMyWorkers` for a server-enforced authenticated-actor scope. Both retain the initial-snapshot and reconnect-reconciliation guarantees of named views.
- Added `CurrentIterationSequence` to worker overview rows and detailed worker-grid rows so active list items can open an iteration stream without embedding iteration output or history in every grid publication.
- Added bounded, replayable per-iteration status streams through `IWorkExecutionContext.Status`, `IWorkSystem.IterationStatuses`, and SignalR. The new surface includes actor-scoped `StreamMyIterationStatus`, sequence cursors, explicit replay-gap messages, atomically attached terminal iteration results, and configurable payload, replay, and subscription limits.
- Added actor-selectivity and iteration publication, replay, concurrency, and system-retention benchmarks.
## Changed
- ASP.NET Core authorization-group resolution now reuses the built-in HTTP claims implementation instead of requiring durable queue consumers to reproduce HTTP-specific claim parsing.
- Durable workflow recovery now resolves authorization groups asynchronously from the persisted actor, retries transient resolution failures with bounded backoff, and remains recoverable across host restarts.
- Durable workflow dispatch explicitly notifies the local queue reader after its workflow transaction commits.
- Waiting for an accepted durable worker issues one immediate reader notification but no longer lowers the configured fallback polling interval to 50 milliseconds.
- Durable queue notifications are local, coalesced while a wake is pending, and backed by fallback polling for cross-process discovery and missed signals.
- Worker-list convenience methods reuse the existing named-view subscription, seed, shared-change-stream, coalescing, authorization, and reconnect path rather than maintaining a second realtime implementation.
- SQL profile parameters now expose `IsBinaryOmitted`; the admin UI renders omitted values explicitly and generates a commented `NULL` placeholder instead of reconstructing unavailable binary data.
- System-wide iteration-status retention now uses an ordered, compacting eviction index so publication at the replay limit does not scan every historical iteration buffer.
## Fixed
- Named-view subscriptions now start their shared change stream before querying the direct seed, hold group broadcasts behind that seed, and reconcile every active state-based view after the shared stream restarts. This prevents a newer update from being overtaken by an older initial snapshot and closes changes that occur during reconnect gaps.
- `WatchWorkerOverview` now sends a complete synchronized initial snapshot, gates subsequent group updates until seeding finishes, and recomputes latest state from worker-keyed changes. Worker detail clients no longer need a separate HTTP read to avoid missing activity during subscription establishment.
- The admin UI now recognizes structured profiling context delivered as either an object or a serialized JSON object, restoring SQL command and parameter display for both representations.
## Security
- Updated the admin UI dependency tree to patched releases, including Next.js and `eslint-config-next` 16.3.0 and PostCSS 8.5.25.
- SQL profiling no longer retains binary parameter bytes. It preserves bounded parameter metadata and emits an explicit `<binary omitted>` marker and `IsBinaryOmitted` flag instead.
- Authorization snapshots are used only when their actor matches the request-context actor; mismatched snapshots are ignored and groups are resolved for the actual caller.
- Named-system HTTP routes now require real access to the selected system in addition to any configured built-in-surface group.
- Removed waiter-driven rapid fallback polling that could sustain unnecessary durable-store claim traffic while accepted callers remained waiting.
- Durable queue notification remains a trusted in-process hint and is not exposed through the built-in HTTP or MCP adapters. Repeated calls cannot build an unbounded signal backlog, though callers should not invoke it continuously without a corresponding committed enqueue.
- `WatchMyWorkers` and `StreamMyIterationStatus` derive their actor from the authenticated SignalR request context, reject callers without a stable actor id, and never trust a browser-supplied actor id for user-scoped access.
- Iteration-status access is filtered through the caller's authorized work-system session, while payload sizes and subscription counts are bounded to limit memory and fanout abuse.