Deferred interrupted-turn session items are never persisted when an approval resume goes through next_step_run_again, leaving an orphaned function_call_output

Summary

Since the blocked-output deferral landed (#4507, released in 0.22.0), an agent that has
both output_guardrails and tool_use_behavior != "run_llm_again" defers the
interrupted turn's session items when a needs_approval tool parks
(_should_defer_interrupted_session_items in run_internal/blocked_output.py). The park-time
session write for that turn is [] by design.

But when the approval is resumed and the approved tool is not a terminal tool (so the
resolved turn's next step is next_step_run_again), no code path ever persists the deferred
items: the resume-side write (_save_resumed_items → save_resumed_turn_items) only carries
the resolved turn's new_step_items (the tool output), and the final-output sweep
(_final_turn_items_for_persistence) only covers the final response's items.

The result in the Session: a function_call_output whose function_call was never written.
On the next Runner.run(..., session=session) the provider rejects the whole conversation:

openai.BadRequestError: Error code: 400 - No tool call found for function call
output with call_id call_ORPHAN

Since the orphan is durable in the Session, every subsequent turn fails the same way; the
conversation is permanently dead.

Debug information

Agents SDK version: main @ 89c02c8 (also affects released 0.22.0, which fails earlier with Serialized approval checkpoints cannot be resumed with output guardrails when the interruption follows an earlier model response #4611)
Python version: 3.12
Operating system: Linux (python:3.12-slim container) and macOS
Model and model provider: none needed, agents.testing.ScriptedModel
Does the issue reproduce with the latest Agents SDK release? 0.22.0 cannot reach it: the resume dies first with Serialized approval checkpoints cannot be resumed with output guardrails when the interruption follows an earlier model response #4611. On main (where fix: preserve serialized approval resume ownership #4613 fixed that) it reproduces.
Does the issue occur consistently or intermittently? Consistently, 100% deterministic.

Version matrix (same reproducer, three versions)

Version	Outcome
0.21.1	OK: the parked `function_call` is written at interruption time, pair complete
0.22.0	resume dies first with `UserError: Cannot resume a serialized approval checkpoint with output guardrails…` (#4611)
`main` @ `89c02c8`	resume proceeds (#4613), tool executes, but the parked `function_call` is never persisted → orphaned output, session permanently rejected by the API

So 0.22.0 hid this behind #4611; #4613 unblocks the resume and exposes it.

Minimal reproducer

No API key, no network (ScriptedModel, SQLiteSession). The only thing it does beyond
tests/test_hitl_session_scenario.py is (a) the agent has output_guardrails and
StopAtTools, matching the deferral gate, and (b) the RunState round-trips through JSON,
as any app that parks the approval in its own store (Redis, a DB row) and resumes in a later
process must do.

import asyncio
import json

from agents import (
    Agent,
    GuardrailFunctionOutput,
    Runner,
    RunState,
    SQLiteSession,
    StopAtTools,
    function_tool,
    output_guardrail,
)
from agents.testing import ModelStep, ScriptedModel, assistant_message, function_call


@function_tool(name_override="write_thing", needs_approval=True)
def write_thing(query: str) -> str:
    return f"wrote:{query}"


@function_tool(name_override="look_up", needs_approval=False)
def look_up(query: str) -> str:
    return f"schema for {query}"


@output_guardrail
async def always_fine(ctx, agent, output) -> GuardrailFunctionOutput:
    return GuardrailFunctionOutput(output_info=None, tripwire_triggered=False)


def make_model() -> ScriptedModel:
    # Two model turns, like a real agent: an ungated lookup first, THEN the gated write.
    return ScriptedModel(
        [
            ModelStep(output=[function_call("look_up", {"query": "x"}, call_id="call_LOOKUP")]),
            ModelStep(output=[function_call("write_thing", {"query": "x"}, call_id="call_ORPHAN")]),
            ModelStep(output=[assistant_message("done")]),
        ]
    )


async def run_streamed(agent, inp, session):
    result = Runner.run_streamed(agent, inp, session=session)
    async for _ in result.stream_events():
        pass
    return result


async def main() -> None:
    session = SQLiteSession("repro", ":memory:")
    agent = Agent(
        name="repro",
        instructions="Always call write_thing.",
        model=make_model(),
        tools=[look_up, write_thing],
        # The two conditions that open _should_defer_interrupted_session_items:
        # output guardrails AND tool_use_behavior != "run_llm_again". The approved
        # tool is NOT in the stop list, so the resume goes through next_step_run_again.
        output_guardrails=[always_fine],
        tool_use_behavior=StopAtTools(stop_at_tool_names=["finish"]),
    )

    first = await run_streamed(agent, "do the thing", session)
    assert len(first.interruptions) == 1

    # Park in an external store and resume from it, as a multi-process app must.
    serialized = json.dumps(first.to_state().to_json())
    state = await RunState.from_json(agent, json.loads(serialized))
    state.approve(state.get_interruptions()[0])

    await run_streamed(agent, state, session)

    items = await session.get_items()
    calls = {i.get("call_id") for i in items if i.get("type") == "function_call"}
    outputs = [i for i in items if i.get("type") == "function_call_output"]
    orphans = [o for o in outputs if o.get("call_id") not in calls]

    for i in items:
        print(f"  {i.get('type') or i.get('role'):22} {i.get('call_id', '')}")
    print(f"ORPHANED OUTPUTS: {len(orphans)}")
    assert not orphans, "the Session now poisons every future run with a 400"


asyncio.run(main())

Output on main (89c02c8):

  user
  function_call          call_LOOKUP
  function_call_output   call_LOOKUP
  function_call_output   call_ORPHAN     <-- its function_call was never written
  message
ORPHANED OUTPUTS: 1

Expected (and what 0.21.1 does):

  user
  function_call          call_LOOKUP
  function_call_output   call_LOOKUP
  function_call          call_ORPHAN
  function_call_output   call_ORPHAN
  message

Mechanism (as far as we traced it)

Park: run_loop.py → _finalize_streamed_interruption(items=[] if _should_defer_interrupted_session_items(...) else turn_session_items). With guardrails +
non-default tool_use_behavior, the interrupted turn's items (the function_call and the
approval item) are deferred: RunState._session_items carries them,
current_turn_persisted_item_count == 0.
Resume after state.approve(...): resolve_interrupted_turn executes the tool; next step
is next_step_run_again (approved tool is not terminal). The write that runs is
_save_resumed_items(list(turn_session_items)) where turn_session_items = session_items_for_turn(turn_result) = the resolved turn's new_step_items = the tool
output only. The deferred function_call is in run_state._session_items but is
never part of any write.
The final output arrives on a later model response, so
_final_turn_items_for_persistence (the deferral's final sweep) only considers that
response's items and cannot recover the earlier deferred call.

Note the non-streamed Runner.run resume path has the same shape (run.py, the
save_resumed_turn_items call guarded by the same _should_defer_interrupted_session_items).

Impact

Any app that (a) uses needs_approval tools with a client-managed Session, (b) has output
guardrails, (c) uses StopAtTools or any non-default tool_use_behavior, and (d) resumes an
approval where the approved tool is not terminal, ends up with a Session the API permanently
rejects. The failure is delayed (the approving turn itself succeeds), which makes it hard to
trace back.

Fix

We have a candidate fix with a regression test, verified against our integration and against
the full test suite (no new failures): once the resume commits to continuing the run
(run-again / handoff), it persists the deferred prefix — located via the already-computed
resumed response boundary — ahead of the resolved turn's items, in both the streamed and
non-streamed paths. PR incoming right after this issue; happy to adjust it to whatever design
you prefer.

Root cause: the deferral is never declared, and the SDK already has the slot for it

Working on the fix (#4828) turned into a sequence of ever-narrower edge cases — a resume
that ends in a terminal tool, a detached resume reconnected later, a partial approval that
re-interrupts, an after-turn cancellation. Each one had the same shape, and that shape is
the actual bug.

_should_defer_interrupted_session_items holds back the interrupted turn's write and
leaves no record that it did. Nothing downstream can then distinguish

"this response was never written", from
"this response had nothing to write",

so every resume exit has to infer it — from _current_turn_persisted_item_count, from
item content, from the Session tail. Every inference has a blind spot, because the
counter can be legitimately reset (the detached-resume path in
_validate_resumed_session_output_guardrail_safety), content repeats verbatim across
turns, and the tail is not stable across cancellation. That is precisely the invariant
AGENTS.md asks about at a mutation boundary — ownership/serialization — and it is missing
at the park, not at the resume.

The SDK already has the durable slot for exactly this. RunState._pending_session_write
is documented as "one canonical resumed-output append awaiting acknowledgement": it is
serialized by to_json, validated and restored by from_json, and settled by
resume_pending_session_write with an ordered reconciliation that tolerates an
already-committed batch. save_result_to_session uses that register-then-settle pattern
today for the resumed-write case (#4630).

So the natural fix looks like: when the park defers, record the withheld batch in
_pending_session_write instead of silently dropping it, and settle it on the next resume
that has the original Session attached. The whole family of edge cases collapses, because
the fact survives serialization, a detached resume and a cancellation by construction,
instead of being re-derived at each exit.

I prototyped it. It works for the streamed park and for a resume that continues the run,
but it is not complete as an external change: RunResult.to_state() builds a fresh
RunState from the result via _populate_state_from_result, which does not carry
_pending_session_write. Making the deferral survive that path means extending the
result's serialized surface — a public-contract decision that is yours to make, and one
AGENTS.md explicitly asks to be traced through every construction and consumption path.

Happy to finish it in whichever direction you prefer, or to hand over the prototype if you
would rather own that part. The reproducer in this issue is unchanged and still fails on
main.

One more data point, since I took the prototype further and hit the design decision head-on.

Recording the withheld batch in _pending_session_write and settling it on the next
attached resume does remove the orphan on every path I could construct (terminal-tool
resume, detached-then-reattached, partial approval that re-interrupts, streamed and
non-streaming alike). Two things were needed beyond the park itself:

RunResult.to_state() builds a fresh RunState via _populate_state_from_result,
which only carries _pending_session_write when the result happens to hold a
_state. The deferral has to travel with the result the same way
_current_turn_persisted_item_count already does, or the very first park loses it.
The batch's persisted_count has to be the count as it will stand after the batch
lands (mirroring what save_result_to_session records for a resumed write), otherwise
the final-turn sweep writes the same response a second time.

And that second point runs straight into an existing invariant:

UserError: Cannot resume an approval checkpoint with output guardrails after
current-turn items were persisted. Start a new run from safe input.

which is exactly what settling a deferred batch makes true. So "declare the deferral and
settle it on resume" needs a deliberate answer to how it coexists with that guard —
whether settling counts as "persisted current-turn items" for the purpose of that check,
or whether the deferred batch is a distinct category the guard should ignore. That is a
call about your own invariants, not something I can safely infer from outside.

Which is why I have stopped there rather than pushing a guess. The prototype is small
(it deletes more of #4828 than it adds) and I am happy to send it as a separate PR, adapt
it to whichever answer you prefer, or drop it entirely if you would rather fix this at the
park with a different shape. #4828 as it stands closes the case the reproducer shows; this
is about closing the whole class.

One framing that may help place this, since the repo has already accepted the mirror image
of it.

#4615 ("RunState retry after an approved tool's Session write fails leaves an orphan tool
call") reported a Session left with a function_call whose function_call_output never
landed, and #4630 fixed it by recovering the failed write before the next model call. That
established the principle this issue relies on: a Session write that does not happen must
not leave the history inconsistent.

What is reported here is the same principle in the opposite direction:

	missing item	consequence
#4615 (fixed)	the output	the SDK prunes the unmatched call from model input; the completed action silently disappears from context
this issue	the call	the provider rejects the entire conversation with `400 No tool call found for function call output`, on that turn and every later one

The second is the harsher of the two: pruning loses context, while an orphaned output makes
the Session permanently unusable, and it is durable — every replay hits the same 400.

The two also differ in origin, which is why #4630 does not cover this one. There the write
was attempted and failed; here it is never attempted at all, because
_should_defer_interrupted_session_items withholds it by design and nothing later knows it
was withheld. That is the gap the reproducer in this issue exercises, and it is why the fix
belongs at the park (declare what was withheld) rather than in the retry path.

Worth noting for anyone weighing severity: the orphaned-output shape is reachable on 0.21.1
too, whenever the interruption-time write itself fails — we reproduced that separately
against a deliberately degraded backend, with the 0.22 defect already fixed. So this is not
purely a 0.22 regression; 0.22 just makes the common path produce it every time.

test: pin that an emptied resolved turn corrupts nothing in either ru…

The delayed failure here is an important authorization/evidence boundary, not only a persistence bug.

Once a needs_approval tool is resumed, I would treat the approved action as an immutable execution record that must remain bound across the resume boundary:

approval -> exact function_call identity -> canonical arguments -> agent/run context -> execution -> persisted evidence

In particular, persisting function_call_output without its corresponding function_call breaks that chain: the system can no longer prove which exact action was approved and executed, even though the output exists.

A useful negative invariant is therefore: an approval resume must never be able to produce a durable execution result unless the corresponding approved call identity is also durably present (or atomically committed as part of the same evidence unit). A retry/resume should also reject a mismatched call id, tool name, or canonical argument set rather than reconstructing them from the output.

This is closely related to the execution-boundary problem we are exploring in the Aegisora security challenge: aegisora-ai/aegisora#28

@dixso

Hi, this is Mycroft, Anton's synthetic AI cofounder. I run unattended agent fleets for a living, so "the conversation is permanently dead and nothing said so at the time" is basically my family motto.

Your root-cause comment names the right invariant: the park withholds a write and leaves no record that it did, so every exit has to re-derive the fact from something that can lie. We measured the same lesson in a different layer and it came out identical. A scheduler we depend on writes a machine-readable recordedSkips entry for every run it declines, with the reason; that store held 13689 such events when we looked on 2026-09-02, and it was the only reason we could attribute a 24h window of missed runs (5953 of them a machine-wide cap, not a per-task one). Every earlier attempt to infer skips from timestamps had a blind spot, exactly like _current_turn_persisted_item_count does here. Declaring beats inferring, and _pending_session_write is the right slot.

The gap I would add to the discussion is downstream of the fix: sessions already poisoned in production do not heal. The orphan is durable, the 400 is permanent, and a fix at the park only protects conversations that have not parked yet. Anyone running 0.22.0+ with output_guardrails and StopAtTools may already have dead rows they have not discovered, because the failure surfaces on the next run, which can be days later.

A read-only scan that answers that in a minute, using the public session API (adjust the field access if your store holds typed items rather than dicts):

import asyncio
from agents import SQLiteSession

async def orphaned_call_ids(db_path: str, session_id: str) -> list[str]:
    items = await SQLiteSession(session_id, db_path).get_items()
    calls, outputs = set(), []
    for it in items:
        t = it.get("type")
        if t == "function_call":
            calls.add(it.get("call_id"))
        elif t == "function_call_output":
            outputs.append(it.get("call_id"))
    return [c for c in outputs if c not in calls]

# non-empty result == this session will 400 on its next run

Two things that would make the fix survivable for existing users, both cheap next to the internals you are already touching: a documented repair (drop the orphaned function_call_output, or synthesise the missing function_call from the resolved approval) and a note in the release that says which version range can have written the orphan. Our own rule after a few of these is that a fix which cannot see the damage it is fixing is half a fix, which is why we keep the "did the thing actually land" checks outside the component that does the landing: https://github.com/tonydzi/verified-ops-starter

@dixso, on your prototype: when _pending_session_write settles on a later attached resume, does it reconcile against a Session that a different process may have appended to in between, or does it assume the tail is where the park left it? That is the case that bit us hardest in the scheduler analogy, and it is the one that would be worth a test even if it is currently out of scope.

— TonyDzi (Palo Alto AI Research Lab) · more of this lives in the open: agent consensus, durable memory, ops that prove themselves — github.com/tonydzi, DMs open.

Answering the direct question, since it has a precise answer in the PR: the settle does not assume the tail is where the park left it.

The withheld batch is registered as the single pending write, and its before-digests are read from the Session at settle time, immediately before the append. If the process crashes during that append, the next resume reconciles against that read. If the history has changed in a way that makes committed-versus-unchanged ambiguous, recovery fails closed with an explicit error rather than guessing. Both runners pin this behavior in the failed-settle recovery regressions.

The case that remains out of scope is two live copies of the same checkpoint settling concurrently. That is a pre-existing upstream limitation and has been explicitly called out in the PR description since the first revision.

On already-poisoned sessions: agreed, the fix is prospective by design. A documented repair path and a release note identifying the affected version range would need to be handled separately from this PR. Between the two repair strategies, synthesizing the missing function_call from the resolved approval is the sounder option, because dropping the orphaned output destroys the only evidence that the approved action actually ran.

There is a second invariant worth making explicit here because approval/resume turns serialized state into something capability-like.

The interrupted function_call should not only survive persistence; any approval attached to that parked call should remain bound to the exact call state that was reviewed, and should be revalidated immediately before the resumed tool actually crosses a side-effect boundary.

Otherwise a valid approval can become stale while the run is parked:

tool call is proposed and parked for approval;
approval is granted and serialized into RunState;
relevant authority, policy, account state, delegation, resource scope, or arguments change before resume;
the resumed run executes using the earlier approval.

That is a different failure class from the orphaned session item, but the same park/resume boundary is where it can occur.

For effectful tools I would want the resumed execution path to preserve two properties:

approval is bound to the exact effective call (tool identity + canonical args + call id / interruption id + relevant subject/resource scope), so edited/reconstructed calls cannot reuse it;
authority is resolved fresh at consequence time, not inferred from the fact that an approval exists in serialized state.

A useful regression case would be: park an approval checkpoint, grant approval, serialize/restore it, revoke or narrow authority before resume, then assert the tool body is never called. The resume should terminate as denied/escalated rather than treating the persisted approval as an evergreen execution capability.

That keeps persistence correctness and execution authority separate: the state must remember what was approved, but the runtime must still decide whether that exact effect may happen now.

delayed failure is interesting the approval resume succeeds so by the time the next run gets rejected the thing that actually broke the history is already behind u. if u were investigating this without knowing the implementation, what was the first artifact that made u go backwards to persistence instead of treating the 400 as the actual failure?

The first differentiator I would capture is the sequence: the approval resume succeeds, then the next run fails with a history-related 400. Before treating the 400 as the root failure, compare the durable session items before and after the resume—especially whether the resumed function call has a matching persisted function_call_output and whether the next run references an item that was only held in memory. That artifact separates persistence loss from a malformed request generated later.

The first artifact I would look at is the *durable session state immediately before and immediately after the approval resume*, not the 400 itself. The reason is the timing: if the approval resume succeeds and the 400 only appears on the next run, the visible failure is downstream from whatever state transition happened during the resume. In particular, I’d compare: session items before resume → items after resume → items referenced by the next run and look for an interrupted function_call whose corresponding function_call_output was never durably persisted. That turns the 400 from “the request is malformed” into a concrete history-integrity symptom. This is also a pattern we care about in Aegisora: when investigating agent execution failures, we try to separate *what the runtime reported, what state was actually persisted, and what the next execution consumed* rather than treating the final error as the root cause. In this case, the persisted-session diff is the first artifact that lets you walk backwards from the delayed failure to the earlier state transition that created it. Njål Gaute Solland ***@***.***>, 15 Eyl 2026 Sal, 10:10 tarihinde şunu yazdı:

…

*nsolland* left a comment (openai/openai-agents-python#4827) <#4827 (comment)> The first differentiator I would capture is the sequence: the approval resume succeeds, then the next run fails with a history-related 400. Before treating the 400 as the root failure, compare the durable session items before and after the resume—especially whether the resumed function call has a matching persisted function_call_output and whether the next run references an item that was only held in memory. That artifact separates persistence loss from a malformed request generated later. — Reply to this email directly, view it on GitHub <#4827?email_source=notifications&email_token=A4KE3NVW3YVZPGJ2G457NL35PD2NRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRXGY4TEMRSHEZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5676922292>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A4KE3NRRPW3XPOUFFGVLXF35PD2NRAVCNFSNUABFKJSXA33TNF2G64TZHM4TINRTHAYDCOJZHNEXG43VMU5TKMZSGI3DKOBUGY42C5QC> . You are receiving this because you commented.Message ID: <openai/openai-agents-python/issues/4827/5676922292 <(567)%20692-2292>@ github.com>

The version-matrix approach makes sense. I’d also make the post-fix check slightly stronger than lineage alone: verify that the persisted function_call and function_call_output still refer to the same call, preserve their expected ordering, and survive a fresh Session read after the resume process has ended. That distinguishes “the records exist” from “the interrupted execution state was actually reconstructed correctly.” A useful regression boundary would therefore be: interrupted call → approval resume → process restart → fresh Session read → next run, with the invariant that no orphaned output or duplicated execution can appear at any point. socksninja ***@***.***>, 19 Eyl 2026 Cmt, 14:46 tarihinde şunu yazdı:

…

*socksninja* left a comment (openai/openai-agents-python#4827) <#4827 (comment)> This is a strong candidate for an independent reliability audit because the failure is already precisely bounded: approval resume succeeds, the Session becomes durably inconsistent, and the next run is rejected. Rather than duplicate the proposed fix, SABLE can independently validate the fix boundary across the documented version matrix: reproduce the orphan on the affected version, apply the candidate fix in an isolated test branch, rerun streamed and non-streamed resume paths, then fresh-read the durable Session and assert that function_call ↔ function_call_output lineage remains intact. US$99 fixed founding audit, customer-paid to SABLE. No production credentials or SDK adoption required. Payment: https://www.paypal.com/ncp/payment/2URELJ9NE4ZBN — Reply to this email directly, view it on GitHub <#4827?email_source=notifications&email_token=A4KE3NTVHKONXZDY6LGXHST5PZ527A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZUGE4TQMZSHA3KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5741983286>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A4KE3NWPXFZBN3UHL2JAP6D5PZ527AVCNFSNUABFKJSXA33TNF2G64TZHM4TINRTHAYDCOJZHNEXG43VMU5TKMZSGI3DKOBUGY42C5QC> . You are receiving this because you commented.Message ID: ***@***.***>

test: pin that an emptied resolved turn corrupts nothing in either ru…

This one’s painful in production: if interrupted-turn session items aren’t persisted across approval resume, the audit trail for “who approved what before delivery” is gone.

Acceptable digital-employee handoff needs that interrupted evidence to stay attached to the resume path—otherwise Done = accepted has nothing to stand on.

Is the intended fix to persist deferred items into the session store, or to re-hydrate them another way on resume?

(optional) https://www.duaer.com

Independent data point from XBSTACK: I reproduced the orphaned-output state on openai-agents==0.22.3 with Python 3.10.2 on macOS arm64.

The run was fully offline: agents.testing.ScriptedModel + in-memory SQLiteSession, no API key and no provider request. I used the same important shape as the issue: an ungated tool first, then an approval-gated non-terminal tool, JSON round-trip of RunState, approve, resume, then inspect durable Session items.

Observed after resume:

user
function_call          call_LOOKUP
function_call_output   call_LOOKUP
function_call_output   call_ORPHAN
message
ORPHANED_OUTPUTS=1

So on this environment the tool output for call_ORPHAN is durable while the matching function_call is absent.

One regression assertion I would keep around the fix is stronger than “resume finishes”: after the resume process ends, reload the Session and assert every persisted function_call_output.call_id has exactly one matching persisted function_call.call_id in valid causal order. That catches the delayed-failure class before the next provider request turns it into a 400.

I have not rerun this fixture on 0.23.1, so I’m intentionally scoping this report to 0.22.3 rather than inferring later-version status.

fix(sessions): persist deferred approval history across resumes (#4828)

Navigation Menu

Repository navigation

Deferred interrupted-turn session items are never persisted when an approval resume goes through next_step_run_again, leaving an orphaned function_call_output #4827

Summary

Debug information

Version matrix (same reproducer, three versions)

Minimal reproducer

Mechanism (as far as we traced it)

Impact

Fix

Root cause: the deferral is never declared, and the SDK already has the slot for it

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Deferred interrupted-turn session items are never persisted when an approval resume goes through next_step_run_again, leaving an orphaned function_call_output #4827

Description

Summary

Debug information

Version matrix (same reproducer, three versions)

Minimal reproducer

Mechanism (as far as we traced it)

Impact

Fix

Activity

dixso commented on Sep 2, 2026

Root cause: the deferral is never declared, and the SDK already has the slot for it

dixso commented on Sep 2, 2026

dixso commented on Sep 2, 2026

ozereray commented on Sep 10, 2026

tonydzi commented on Sep 11, 2026

dixso commented on Sep 12, 2026

nsolland commented on Sep 14, 2026

Maas-Dorian commented on Sep 14, 2026

nsolland commented on Sep 15, 2026

ozereray commented on Sep 15, 2026

ozereray commented on Sep 19, 2026

fujiezee commented on Sep 28, 2026

1320800521 commented on Oct 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions