FAILURE MAP
← Case archive

FA-99846 / Agent workflow termination / Open access

Workflow: final answer is accepted with tools still pending · case 01

A workflow closes while an issued tool request has no result.

Verified by executionVariant 1 · 7 checks per implementationDownload source bundle ↓JSON ↗

ROOT CAUSE

Completion checks only the assistant turn flag and ignores outstanding requests.

THE FAILURE

Completion checks only the assistant turn flag and ignores outstanding requests.

Unsuccessful approach: Checking only the pending count accepts a run with no final answer once its tools are drained.

Case contract

A run is complete iff final_seen is true and pending_count is zero.

Why this case matters

This toy decision rule isolates one bounded agent-loop completion contract.

1 / The failure

Exit 1
"""Failure Map reference implementation. Python standard library only."""
import json

N = 1
observations = []
def solve(final_seen, pending_count):
    return bool(final_seen)
def check(label, actual, expected):
    observations.append({"check": label, "actual": actual, "expected": expected, "passed": actual == expected})
check('final and clear', solve(True,0),True)
check('final pending', solve(True,N),False)
check('no final clear', solve(False,0),False)
check('no final pending', solve(False,N),False)
check('one request pending', solve(True,1),False)
check('no final with extra pending', solve(False,N+1),False)
check('final with larger outstanding batch', solve(True,N+1),False)
print(json.dumps({"observations": observations, "passed": all(x["passed"] for x in observations)}, ensure_ascii=False))
raise SystemExit(0 if all(x["passed"] for x in observations) else 1)
Boundary fixtureActualExpectedOutcome
final and clearTrueTruePassed
final pendingTrueFalseFailed
no final clearFalseFalsePassed
no final pendingFalseFalsePassed
one request pendingTrueFalseFailed
no final with extra pendingFalseFalsePassed
final with larger outstanding batchTrueFalseFailed

SHA-256 / 81e6a2ba17e87ad81aeb60d3c7b974e48e3d1187fd6e9fbf9f9b40bd0b526119

2 / The unsuccessful fix

Exit 1
"""Failure Map reference implementation. Python standard library only."""
import json

N = 1
observations = []
def solve(final_seen, pending_count):
    return pending_count == 0
def check(label, actual, expected):
    observations.append({"check": label, "actual": actual, "expected": expected, "passed": actual == expected})
check('final and clear', solve(True,0),True)
check('final pending', solve(True,N),False)
check('no final clear', solve(False,0),False)
check('no final pending', solve(False,N),False)
check('one request pending', solve(True,1),False)
check('no final with extra pending', solve(False,N+1),False)
check('final with larger outstanding batch', solve(True,N+1),False)
print(json.dumps({"observations": observations, "passed": all(x["passed"] for x in observations)}, ensure_ascii=False))
raise SystemExit(0 if all(x["passed"] for x in observations) else 1)
Boundary fixtureActualExpectedOutcome
final and clearTrueTruePassed
final pendingFalseFalsePassed
no final clearTrueFalseFailed
no final pendingFalseFalsePassed
one request pendingFalseFalsePassed
no final with extra pendingFalseFalsePassed
final with larger outstanding batchFalseFalsePassed

SHA-256 / 2dc80a3a6edc477428a6bdf4e59c232a6444ab81d90c8519ad9d3fff0219b70c

HELD IN THE MEMBER ARCHIVE

The verified repair and its recorded checks are member-only.

This mechanism has 7 recorded checks per implementation. The open-access tier publishes the failure and the unsuccessful fix; the repaired source that passes every check, and the observations that prove it, are available to members.

Every case sharing this mechanism uses the same contract and the same repair, so this one record is held back for all of them.

Member access is invitation-based. Sign in with your invited account to inspect the repair.

Sign in to the archive ↗

Verification & scope

Pending count is an already validated nonnegative count. This reproducer isolates one failure mechanism. Results cover the supplied fixtures. Variants within a family share a test contract and should remain grouped when constructing evaluation splits. Related mechanisms with a shared evaluation_group must also remain together; these controlled models are not independent production incidents.

Observations recorded using Python 3.12.14 at 2026-09-30T16:48:28.969790+00:00.

Case digest / d29f2b368be98cac20bb290843a0ed9159e67c92577af4e921fd8bd1d925bb25