* feat(core): first-class fatal signal (MiddlewareFailure) for function middleware
The function-invocation loop converts every exception raised by
function middleware into a tool-error result and keeps looping, so
middleware that needs fail-closed semantics (enforcement layers,
guardrails) had no loud escape: the agent-hooks feature simulated one
by mutating shared run state, raising MiddlewareTermination, and
re-raising the real failure two hops away at the run boundary.
Introduce MiddlewareFailure (a MiddlewareException sibling of
MiddlewareTermination) as the loop's explicit fail-closed escape:
- _auto_invoke_function re-raises it (both the direct and the
pipeline path) instead of absorbing it into a tool-error result;
ordinary exceptions keep the absorb-and-continue contract.
- A failing call fails the whole parallel batch: in-flight sibling
tool tasks are cancelled and awaited before the failure propagates.
- Every existing MiddlewareTermination absorb site (agent/chat
pipelines, _execute_single_function_call, harness loop, purview)
passes it through untouched by construction, and agent/chat
middleware exceptions already propagate, so one exception type
gives uniform fail-loud semantics across all three categories.
Migrate the agent-hooks feature to the new signal: delete the
_RunState.halted back-channel and its three run-boundary re-raise
checks, drop the halted arm of the termination special case in the
function middleware (the approval-request pass-through moves to the
single approval check on the normal path), and fail partial installs
loudly. Tool-seam host_error blocks keep surfacing as
InterceptionBlocked at the run boundary via the exception cause chain
(one deny surface at every seam, pinned by tests).
Spec 004 gains the middleware-failure invariants and matrix rows.
Closes#7522
Signed-off-by: MohammadHaroonAbuomar <40180927+MohammadHaroonAbuomar@users.noreply.github.com>
* fix(core): harden tool-seam unwrap and pin review findings
Review round follow-ups for the MiddlewareFailure feature:
- Only agent-hooks' own tagged tool-seam halts (_ToolSeamBlockFailure)
authorize re-raising the chained InterceptionBlocked at the run
boundary; a third-party MiddlewareFailure with a crafted
InterceptionBlocked cause now propagates as raised instead of
laundering an attacker-shaped interception record into the feature's
deny surface (regression test added, verified by mutation).
- Document that middleware must not catch MiddlewareFailure (docstring
and spec 004): swallowing it converts a fail-closed abort back into
a running, possibly unguarded loop.
- Pin the trailing termination re-raise in the agent-hooks function
middleware: an inner short-circuit is bracketed and still propagates,
skipping outer middleware post-code (test fails with the re-raise
removed).
Signed-off-by: MohammadHaroonAbuomar <40180927+MohammadHaroonAbuomar@users.noreply.github.com>
* fix(core): acyclic tool-seam unwrap chain; document cooperative batch cancellation
Address two automated-review findings on the MiddlewareFailure PR,
both confirmed empirically:
- _reraise_tool_seam_block created a two-object exception-chain cycle
(block.__cause__ -> wrapper -> block) by re-raising the chained
InterceptionBlocked `from` its transport wrapper. Detach the
wrapper's back-links and re-raise bare, recording the wrapper as
the block's __context__ — acyclic, both exceptions still visible in
tracebacks. Regression test walks the chain and pins finiteness
(verified to fail against the cyclic re-raise).
- Batch cancellation is cooperative: a synchronous tool body already
running in a worker thread (asyncio.to_thread) cannot be interrupted
by task cancellation and may complete its side effects after the
failure reached the caller; its result is discarded either way and
propagation is not delayed behind it. Narrow the stated contract
(MiddlewareFailure docstring, loop comment, spec 004) and pin it
with a blocking-sync-sibling regression test.
Signed-off-by: MohammadHaroonAbuomar <40180927+MohammadHaroonAbuomar@users.noreply.github.com>
* fix(core): settle dangling calls on service-managed conversations on abort
Address maintainer review on the MiddlewareFailure PR:
- A MiddlewareFailure escaping a tool batch on a service-managed
conversation left the hosted thread ending in unresolved
function_call items: _update_continuation_state persists
session.service_session_id when the model turn completes (before
tool execution), and probe-verified the next run sends only the new
user message against that conversation — OpenAI-style continuations
reject such a request, so a routine policy abort left the session
permanently stuck. Both loops now settle the thread before
propagating: one error function_result per dangling call, submitted
with tool_choice="none" in a single extra request whose response is
discarded; a settlement failure never masks the abort, and runs
without a service-managed conversation make no extra request.
Pinned by three regression tests (non-streaming, streaming, and the
no-conversation no-cost case); spec 004 and the MiddlewareFailure
docstring updated.
- Make the three tool-bracket escape tuples in the agent-hooks
function middleware identical (MiddlewareTermination,
MiddlewareFailure, CancelledError): a MiddlewareFailure raised
inside the post/error-bracket emit bodies is unreachable today, but
the uniform tuples remove the need to reason about why they would
differ, and preserve the exact exception (including the private
tool-seam tag) if the emitter ever surfaces one.
Signed-off-by: MohammadHaroonAbuomar <40180927+MohammadHaroonAbuomar@users.noreply.github.com>
* fix(core): advance settled continuation; settle approved-replay aborts
Address maintainer review on the MiddlewareFailure settlement path,
both probe-verified (branch rebased onto current main first):
- Advance the persisted continuation to the settlement response. For
response-ID continuations (OpenAI Responses store=True, where the
response id is the continuation handle) the settlement response is
the first endpoint whose chain includes the synthetic tool outputs;
leaving session.service_session_id on the pre-settlement response
made the settlement ineffective — the next run would continue from
the still-unresolved turn. The settlement response now runs through
_update_function_invocation_continuation_state (a no-op for stable
conversation-object ids). Pinned by a regression test that fails
with the advance removed.
- Cover the approval-resolution phase: a MiddlewareFailure raised
while an approved tool is replayed escapes loudly (probe-verified,
already the case) but executed before the loops' settlement seams,
leaving the original — already service-persisted — call unresolved.
_resolve_approval_responses now takes a settle_dangling_calls
callback invoked with the approved batch on abort; the settlement
helper became a layer method taking explicit calls
(approval-response wrappers unwrap to their underlying calls,
hosted-tool approvals are left to their provider protocol) and
carries its own best-effort containment. Pinned by deny-during-
replay regression tests in both response modes, mutation-verified.
Spec 004 invariants and matrix rows updated accordingly.
Signed-off-by: MohammadHaroonAbuomar <40180927+MohammadHaroonAbuomar@users.noreply.github.com>
---------
Signed-off-by: MohammadHaroonAbuomar <40180927+MohammadHaroonAbuomar@users.noreply.github.com>
MohammadHaroonAbuomar
58da0cc253