You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[agentserver] Separate Invocations and Responses task-runtime activation - #49616
Stored foreground execution; disconnect cancellation remains. An initialized task runtime marks interrupted foreground work failed rather than re-invoking it.
false
true
HTTP 400: background=true requires store=true.
false
false
Ephemeral foreground execution, no task-backed steering/recovery.
Graceful shutdown still best-effort marks unfinished non-resilient responses failed even without TaskManager. SSE backing, persistent-response-provider validation, checkpoint consumption and recoverable shutdown preservation retain their existing resilient_background gates.
Isolation and implementation
Cooperative protocol registration contributes independent startup requirements in either multiple-inheritance order.
Keep the task manager on its owning host and bind access through context-local lifecycle/request scopes, including HTTP and Invocations WebSocket routes.
An enabled protocol does not expose its manager to disabled protocol handlers. Both-disabled Responses bypasses task dispatch explicitly, even if the Invocations switch is on.
Late task registration follows the scoped manager. Shutdown clears only its own compatibility singleton.
Preserve eager internal task registration before startup recovery and existing persisted dispositions; do not replace the registry or recovery algorithms.
Startup construction/initialization errors still fail the lifespan.
The low-level Core host retains its standalone switch-based behavior for compatibility.
Compatibility and packaging
This deliberately changes two configurations:
Steering-only Responses now initializes TaskManager automatically; no separate core switch call is required.
Setting the core switch no longer forces task execution for Responses with both feature options false.
Both protocol packages require azure-ai-agentserver-core>=2.3.0b2 because scoped runtime support is a coordinated core/protocol change. No new dependency names, public constructor arguments, versioning feature, registry auto-enablement or task-provider type is introduced.
The unreleased notes use versioned release headings, aligned with runtime and API metadata: Responses 2.4.0b2 and Invocations 1.2.1b1. Existing released entries are preserved.
Updated package changelogs, related guides, conformance setup and Responses samples. The experimental-marker and steering-handoff changes already on main remain intact.
Responses e2e/conformance on Windows: 185 passed, 78 skipped.
Invocations non-live suite: 665 passed, 3 skipped, with 3 live tests deselected; all 18 new protocol/MRO/HTTP/WS cases pass.
POSIX crash tests in WSL: 5 passed, including both-disabled and steering-only Row 2 recovery.
Real hard-stop/restart with the Invocations switch false in both process lifetimes: steering-only mode marks interrupted A failed and executes queued B; resilient steering re-invokes A and then executes B. Responses never changes the switch.
Pylint: 10.00/10 across the 10 changed production modules.
Mypy passed on changed production modules; full-package Pyright has zero errors for all three packages. Existing warnings occur only in unchanged files.
Repository-pinned Black at the repository's 120-column setting and git diff --check pass.
Keep the explicit task switch for Invocations and derive Responses activation from resilient_background or steerable_conversations. Scope runtime access by host and protocol without changing persistent backends, request mode semantics, or recovery dispositions.
Add activation/request matrices, mixed-host and WebSocket isolation coverage, startup failure checks, and feature-driven crash conformance. Update minimum core requirements and related samples/docs.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b3f38ee6-97fe-4707-8f3d-5a1169666792
Azure Pipelines:
Successfully started running 1 pipeline(s).
10 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.
Describe feature-driven startup, steering-only recovery, and the lack of task-based locking/crash cleanup when both Responses flags are disabled.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b3f38ee6-97fe-4707-8f3d-5a1169666792
Use versioned preview headings so version-specific release-note extraction includes the protocol activation and dependency changes. Preserve released history and align runtime/API metadata versions.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b3f38ee6-97fe-4707-8f3d-5a1169666792
[P2] Capture Invocations enablement per host at lifespan startup. The HTTP resolver created here and the WebSocket resolver in _invocation_ws.py:190 re-read the process-wide switch on every manager lookup. If host A starts enabled, setting the switch to False before starting host B removes task access from A's handlers and existing WebSocket sessions even though A's manager is still running. Conversely, switching to True exposes a Responses-enabled mixed host's manager to Invocations that started disabled. Record each protocol's activation decision at startup and use that same state for HTTP and WebSocket scopes. Add overlapping-host coverage that changes the switch between host startups.
Invocations request scoping reads the live process-wide switch rather than the host's startup decision. If host A starts with the switch enabled, then it is disabled before starting host B, A's HTTP handlers lose access to its still-running manager and task calls raise TaskManagerNotInitialized. The WebSocket lookup in _invocation_ws.py:190 has the same problem. Capture each protocol's enablement at lifespan startup and use that host-local decision for both HTTP and WebSocket scopes. Add an overlapping-host test that changes the switch between startups and verifies A retains access.
Apply invocation task scoping to Voice WebSocket routes
This middleware covers only the base WebSocket route. VoiceAgentServerHost overrides route registration and creates _VoiceWebSocketRoute without middleware (voice/_voice_host.py:189–190,589–604); it also overrides _ws_endpoint. In a composed Voice/Responses host with Invocations disabled and Responses enabled, voice callbacks therefore inherit Core's host-wide scope and can access the Responses manager. Apply Invocations task scoping to the Voice route too, and add a mixed-host test proving disabled voice callbacks cannot obtain the manager.
Review effort: Balanced
This branch has not been deployed
No deployments
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Separate task-runtime activation for the Invocations and Responses protocols.
set_resilient_tasks_enabled(True)before host startup.resilient_backgroundorsteerable_conversationsis true, independently of the Invocations switch.Based on freshly fetched
mainatcddd0ee8fe3c0fe2453ee38af71b9c4bf64ae7b5.Responses server-option truth table
For requests with
store=true, background=true:resilient_backgroundsteerable_conversationsin_progress.Steering-only mode retains durable task control state and recovery bookkeeping. It is not memory-only or a mode without a recovery scanner.
Request behavior stays unchanged
storebackgroundbackground=true requires store=true.Graceful shutdown still best-effort marks unfinished non-resilient responses failed even without TaskManager. SSE backing, persistent-response-provider validation, checkpoint consumption and recoverable shutdown preservation retain their existing
resilient_backgroundgates.Isolation and implementation
Compatibility and packaging
This deliberately changes two configurations:
Both protocol packages require
azure-ai-agentserver-core>=2.3.0b2because scoped runtime support is a coordinated core/protocol change. No new dependency names, public constructor arguments, versioning feature, registry auto-enablement or task-provider type is introduced.The unreleased notes use versioned release headings, aligned with runtime and API metadata: Responses
2.4.0b2and Invocations1.2.1b1. Existing released entries are preserved.Updated package changelogs, related guides, conformance setup and Responses samples. The experimental-marker and steering-handoff changes already on main remain intact.
Validation
git diff --checkpass.