FA-99881 / Agent workflow termination / Open access

Workflow: completion is delayed after the last result drains the queue · case 01

The final result drains the queue, but the completion check still sees the pre-result count.

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

ROOT CAUSE

Completion is tested against the pending count before the latest result transition.

THE FAILURE

Completion is tested against the pending count before the latest result transition.

Unsuccessful approach: Treating one remaining item as drained can stop before its final result arrives.

Case contract

Return complete iff pending_before - received is zero; received is zero or one and cannot exceed pending_before.

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(pending_before, received):
    return pending_before == 0
def check(label, actual, expected):
    observations.append({"check": label, "actual": actual, "expected": expected, "passed": actual == expected})
check('last result drains', solve(1,1),True)
check('still one pending', solve(N,0),False)
check('already drained', solve(0,0),True)
check('whole batch drains', solve(N,N),True)
check('no result pending', solve(1,0),False)
check('multiple drained by one', solve(2,1),False)
check('one still pending', solve(N+1,N),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 fixture	Actual	Expected	Outcome
last result drains	`False`	`True`	Failed
still one pending	`False`	`False`	Passed
already drained	`True`	`True`	Passed
whole batch drains	`False`	`True`	Failed
no result pending	`False`	`False`	Passed
multiple drained by one	`False`	`False`	Passed
one still pending	`False`	`False`	Passed

SHA-256 / 2c8865673b3315c7ddc886ace2ac9b61635c57b4ebb5f30f596f57f8f37ae5a1

2 / The unsuccessful fix

Exit 1

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

N = 1
observations = []
def solve(pending_before, received):
    return pending_before - received <= 1
def check(label, actual, expected):
    observations.append({"check": label, "actual": actual, "expected": expected, "passed": actual == expected})
check('last result drains', solve(1,1),True)
check('still one pending', solve(N,0),False)
check('already drained', solve(0,0),True)
check('whole batch drains', solve(N,N),True)
check('no result pending', solve(1,0),False)
check('multiple drained by one', solve(2,1),False)
check('one still pending', solve(N+1,N),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 fixture	Actual	Expected	Outcome
last result drains	`True`	`True`	Passed
still one pending	`True`	`False`	Failed
already drained	`True`	`True`	Passed
whole batch drains	`True`	`True`	Passed
no result pending	`True`	`False`	Failed
multiple drained by one	`True`	`False`	Failed
one still pending	`True`	`False`	Failed

SHA-256 / 8362ab82c2d00fd665e1f82841ca93245d93690dde8284ee2f42f7b52896d02a

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.

Verification & scope

Inputs satisfy 0 <= received <= pending_before. 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:29.419209+00:00.

Case digest / 0f7dee1ea3d7642054e226d07e7bdb3e4c522a34200e2288412343091d44235e