Rest a co-op fetch goal that cannot be routed to

[saworbit]

A co-op companion on e1m6 logged 400 routefails in 175 s against four goal pushes. The cause is two halves that only loop together.

Argus_AI clears ar_goal on every routefail. The GOAL_FETCH branch of the co-op dispatch re-adopts its subject the moment ar_goal is not already it, and only pops when the item stops existing. So the pair retries at think rate for the whole 45 s life of the goal, and the co-op layer then re-pushes it.

Why the obvious guard does not work

The item shelf cannot cover this. ar_failtime is only stamped when the failure comes from a different area, because a global shelf stamped by a trapped bot starves every other bot through PickGoal's menu. A bot hammering one objective mills inside a single patch, so it takes the failstreak branch every time and the shelf is never set.

That is also why an earlier attempt failed. Putting the shelf check on Argus_CoopCommitKey changed nothing, because the retries come from the goal already on the stack rather than from re-commitment. It also cost e1m2 routefails 0 to 77 and stalls 40 to 73, and was reverted.

The fix

A routefail whose goal is the current fetch subject rests that bot for 20 s, the same constant the item shelf uses.

Two deliberate choices:

• Per-bot, not the global item shelf. This is a verdict about one bot's ability to route there, and shelving a shared co-op objective is exactly how one stuck bot would starve a whole team.
• ar_goal left clear rather than the goal popped. The caller runs Argus_PickGoal whenever the goal is world, so the bot shops normally for those 20 s instead of standing still, and the objective is retried afterwards rather than abandoned. The goal stays on the stack throughout.

e1m6, two tapes each side

	routefails	cells	busiest cell	stalls	freezes
before	400, 377	6, 9	57%, 57%	6, 2	0
after	8, 9	23, 22	10%, 8%	7, 3	0

The bot stops being parked in one cell and works the map while its objective rests. e1m6 still cannot be finished, because the gold key sits behind a func_door that rises on a trigger_once chain nothing fires in a botmatch. This makes the failure cheap instead of constant, which matters because an_busy serialises the router and one bot failing twice a second starves the others.

dm4, 180 s

Routefails 10 against 9, stalls 4 against 18, cells 74 against 75, goals 157 against 126, no freezes.

e1m2 is untouched by construction

ar_routefail is set in exactly one place, immediately before the routefail event print, so events map one to one with the flag. Both e1m2 tapes log zero, so the guard never executes there.

Worth recording rather than hiding: the coverage on those tapes reads 31 and 50 cells against 52, 55 and 55 earlier, on code that provably cannot behave differently. That is e1m2 co-op variance, and a caution against judging co-op on a single tape. The 6 to 8 second freezes on e1m2 are the pre-existing give-up-capped class, and the shipped build's own tape carries one.

Refs #249

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.