Summary
The push_wiki batching bug from #281 is still present on main. #281 was closed as completed, but the workflow prompt still instructs the agent to split pages across multiple push-wiki calls, while the safe-output remains capped at 1 invocation per run. The result is the exact failure #281 described: only the first batch publishes, the rest are silently dropped, and the surviving pages link to pages that never made it to the wiki (dead [[wiki-links]]).
Evidence (current workflows/agentic-wiki-writer.md on main)
The conflicting instructions are still there:
- Step 3d, line ~294: "Never generate more than 4 pages per
push-wiki call. If there are more than 4 pages to generate, process them in sequential batches of up to 4, calling push-wiki once per batch."
- Step 3f, line ~318: "Push in batches of at most 4 pages per call" → steps 320–325 describe dividing pages into batches and calling
push-wiki once per batch.
But push-wiki is a custom safe-output job, which is hard-capped at 1 call. Observed run output:
Too many items of type 'push_wiki'. Maximum allowed: 1. (items #66–#71)
Only batch 1 (Home.md, Architecture.md) was pushed; batches 2–7 (the rest of the pages + _Sidebar.md) were rejected, leaving dead links from Home/Sidebar to [[Getting-Started]], [[Backend]], etc.
Note on fix option 2 (raise the cap)
Fix option 2 from #281 ("increase the max limit") does not appear viable for a custom safe-outputs.jobs entry: adding max: to the push-wiki job fails compilation on gh-aw v0.80.9:
error: Unknown property: max. 'max' belongs under 'safe-outputs/reply-to-pull-request-review-comment',
'safe-outputs/assign-milestone' or 'safe-outputs/update-issue'
So option 1 (single call) is the only prompt-level fix unless gh-aw exposes a per-custom-job invocation cap.
Suggested fix (option 1 — single call)
Rewrite the Step 3d / Step 3f batching instructions to have the agent call push-wiki exactly once with every page in one files object (including _Sidebar.md). Since the push-wiki job clones the existing wiki and git add -As, incremental runs only need the changed pages in the one call (untouched pages persist from the checkout); full regen puts all pages in the single call, so keep pages concise to bound the payload.
This works in practice — patched locally and the broken-link problem is resolved.
Summary
The
push_wikibatching bug from #281 is still present onmain. #281 was closed as completed, but the workflow prompt still instructs the agent to split pages across multiplepush-wikicalls, while the safe-output remains capped at 1 invocation per run. The result is the exact failure #281 described: only the first batch publishes, the rest are silently dropped, and the surviving pages link to pages that never made it to the wiki (dead[[wiki-links]]).Evidence (current
workflows/agentic-wiki-writer.mdonmain)The conflicting instructions are still there:
push-wikicall. If there are more than 4 pages to generate, process them in sequential batches of up to 4, callingpush-wikionce per batch."push-wikionce per batch.But
push-wikiis a custom safe-output job, which is hard-capped at 1 call. Observed run output:Only batch 1 (
Home.md,Architecture.md) was pushed; batches 2–7 (the rest of the pages +_Sidebar.md) were rejected, leaving dead links from Home/Sidebar to[[Getting-Started]],[[Backend]], etc.Note on fix option 2 (raise the cap)
Fix option 2 from #281 ("increase the max limit") does not appear viable for a custom
safe-outputs.jobsentry: addingmax:to thepush-wikijob fails compilation on gh-aw v0.80.9:So option 1 (single call) is the only prompt-level fix unless gh-aw exposes a per-custom-job invocation cap.
Suggested fix (option 1 — single call)
Rewrite the Step 3d / Step 3f batching instructions to have the agent call
push-wikiexactly once with every page in onefilesobject (including_Sidebar.md). Since thepush-wikijob clones the existing wiki andgit add -As, incremental runs only need the changed pages in the one call (untouched pages persist from the checkout); full regen puts all pages in the single call, so keep pages concise to bound the payload.This works in practice — patched locally and the broken-link problem is resolved.