FAILURE MAP
← Case archive

FA-99841 / Agent workflow termination / Open access

Workflow: terminal state is ignored while budget remains · case 01

A completed or failed run is scheduled for another step.

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

ROOT CAUSE

The admission rule checks only remaining budget, so terminal status is ignored.

THE FAILURE

The admission rule checks only remaining budget, so terminal status is ignored.

Unsuccessful approach: Stopping only on successful completion continues after failure.

Case contract

Return true when status is complete or failed; a nonterminal status returns false regardless of remaining steps.

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(status, remaining):
    return remaining <= 0
def check(label, actual, expected):
    observations.append({"check": label, "actual": actual, "expected": expected, "passed": actual == expected})
check('complete with room', solve('complete',N),True)
check('failed with room', solve('failed',N),True)
check('running with room', solve('running',N),False)
check('running exhausted', solve('running',0),True)
check('failed exhausted', solve('failed',0),True)
check('waiting with room', solve('waiting',N),False)
check('unknown is nonterminal', solve('paused',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
complete with roomFalseTrueFailed
failed with roomFalseTrueFailed
running with roomFalseFalsePassed
running exhaustedTrueTruePassed
failed exhaustedTrueTruePassed
waiting with roomFalseFalsePassed
unknown is nonterminalFalseFalsePassed

SHA-256 / 6393c1ec18f95d678ddf6afcdd321fb7cbd0b8f7083a18aaff58339a7e3704e6

2 / The unsuccessful fix

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

N = 1
observations = []
def solve(status, remaining):
    return status == 'complete' or remaining <= 0
def check(label, actual, expected):
    observations.append({"check": label, "actual": actual, "expected": expected, "passed": actual == expected})
check('complete with room', solve('complete',N),True)
check('failed with room', solve('failed',N),True)
check('running with room', solve('running',N),False)
check('running exhausted', solve('running',0),True)
check('failed exhausted', solve('failed',0),True)
check('waiting with room', solve('waiting',N),False)
check('unknown is nonterminal', solve('paused',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
complete with roomTrueTruePassed
failed with roomFalseTrueFailed
running with roomFalseFalsePassed
running exhaustedTrueTruePassed
failed exhaustedTrueTruePassed
waiting with roomFalseFalsePassed
unknown is nonterminalFalseFalsePassed

SHA-256 / a128adddfec27ce98c708ebdc0d3aebfb23784a4c0488dc36e41c1303b0502b6

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

Statuses are a finite toy vocabulary; this is not a framework state machine. 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.969383+00:00.

Case digest / e5768ece261bc4f42c07f5007ed73f191df348cecfaf147542b57e9d911c6238