>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3588767. --> Reported by: [ajv009](https://www.drupal.org/user/3653917) >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>The menu-builder agent misidentifies Drupal's post-save 302 redirect (<code>/admin/structure/menu/item/&lt;id&gt;/edit</code>) as an SSO failure. Each misidentified "failure" causes the orchestrator to dispatch a fresh menu-builder subagent with an ~18-minute startup delay. In a recorded migration session against an Acquia Source instance, this pattern produced 4 dispatch attempts over 64 minutes for the footer menu, after which the agent gave up and wrote <code>blocked.md</code> with manual instructions for the user. The same bug surfaced in an earlier session as 52 minutes of idle time. The footer menu was never automated across either session.</p> <p>Two distinct issues stack together:</p> <ol> <li><strong>Success-redirect misidentification:</strong> The agent sees a 302 after form POST and treats any redirect as a failure. It does not check whether the destination is a Drupal admin URL (<code>/admin/structure/menu/item/&lt;id&gt;/edit</code> = success) versus an SSO/WAF URL (<code>source.acquia.com</code>, <code>id.acquia.com</code>, <code>/sites/default/files/simplesamlphp/*</code> = genuine failure). Both look like "redirected away from the form" but mean opposite things.</li> <li><strong>Retry storm on genuine WAF blocks:</strong> When a real WAF block does occur, the menu-builder triggers up to 3 fresh subagent dispatches with ~18-minute gaps each. Total: 64 minutes of idle time. The user expects up to 4 in-process retries with fresh page loads, not 3 full subagent re-dispatches.</li> </ol> <p>User feedback during the session was direct: "you should be able to do this, if you get redirected to /sites go back and do this again why stop?"</p> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <ol> <li>Run the migrate-site skill against an Acquia Source instance that requires SSO/WAF cookies for admin POSTs.</li> <li>Reach Phase 6 (Drupal menu configuration) with at least one menu (e.g., footer) to populate.</li> <li>Observe: the menu-builder POSTs the first menu item, Drupal redirects to <code>/admin/structure/menu/item/&lt;id&gt;/edit</code> on save success, and the agent declares SSO failure.</li> <li>Observe: the orchestrator dispatches additional menu-builder subagents with ~18-minute gaps. Each fails identically.</li> <li>After 3&ndash;4 dispatches, the agent writes <code>blocked.md</code> with manual menu instructions; total dead time ~64 minutes.</li> </ol> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p><strong>Step 1 &mdash; Add SUCCESS REDIRECT DETECTION block to <code>.claude/agents/menu-builder.md</code>:</strong></p> <pre>SUCCESS REDIRECT DETECTION: When the menu item save form redirects to /admin/structure/menu/item/&lt;ID&gt;/edit, this is a DRUPAL SUCCESS REDIRECT &mdash; the item was saved successfully. DO NOT treat this as an SSO failure. DO NOT retry. Log: "Menu item saved &mdash; confirmed by edit redirect to /item/&lt;ID&gt;/edit" FAILURE PATTERN (genuine SSO): If redirected to id.acquia.com, source.acquia.com, or /sites/default/files/simplesamlphp/* &mdash; THIS is a genuine auth failure. Retry with fresh browser session up to 4x.</pre><p><strong>Step 2 &mdash; Add RETRY LIMIT block to <code>.claude/agents/menu-builder.md</code>:</strong></p> <pre>RETRY LIMIT: 1 If the menu automation fails after 1 genuine SSO retry: 1. Write blocked.md with the specific failure (which menu, which items, which URL) 2. Write a manual step-by-step clickable list for the user 3. DO NOT dispatch more than 1 retry attempt 4. Log: "menu_builder_blocked" to state.jsonl 5. Continue to next phase &mdash; do NOT block the entire migration on menu failures The cost of 3 retry dispatches with 18-min gaps is 64 min dead time. One retry maximum.</pre><p><strong>Step 3 &mdash; Update SKILL.md Phase 6:</strong> add "If <code>menu_builder_blocked</code> appears in <code>state.jsonl</code>, skip to Phase 7 immediately. Do not hold the entire migration waiting for manual menu creation. <code>blocked.md</code> contains manual instructions for the user."</p> <p><strong>Step 4 (medium-effort) &mdash; Verify-browser-session cookie persistence:</strong> investigate seeding the <code>.canvas-browser/</code> Chrome profile with cookies from a user-authenticated session so genuine WAF blocks happen less often. This is the deeper fix; Steps 1&ndash;3 are the immediate dead-time elimination.</p> <p>Empirical note (probed 2026-05-01): the API-first alternative (<code>menu:administer</code> scope, see 2-05) was confirmed blocked on the current Acquia Source release. <code>POST /api/menu_items/main</code> returns HTTP 405 (<code>Allow: GET, HEAD</code>); <code>/api/menu_link_content/menu_link_content</code> returns HTTP 404. The browser-automation fix in this issue remains the PRIMARY and ONLY available path for menu management until those endpoints land.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>Add SUCCESS REDIRECT DETECTION and RETRY LIMIT blocks to <code>.claude/agents/menu-builder.md</code>.</li> <li>Add Phase 6 update to <code>.claude/skills/migrate-site/SKILL.md</code> for the <code>menu_builder_blocked</code> state-skip.</li> <li>Add <code>docs/migration/workflow/blocked.md</code> template artifact with the documented format.</li> <li>Verify on a staging Acquia instance: a Drupal success redirect is recognized as success; a simulated WAF redirect causes 1 retry, then <code>blocked.md</code> is written and the orchestrator proceeds to Phase 7.</li> <li>Total Phase 6 dead-time for the blocked case is bounded at ~18 min (1 retry), not 64 min.</li> <li>Investigate whether the <code>.canvas-browser/</code> profile can be seeded with authenticated cookies as a deeper fix.</li> </ul> <h3 id="summary-ui-changes">User interface changes</h3> <p>None.</p> <h3 id="summary-api-changes">API changes</h3> <p>None. Existing <code>agent-browser</code> commands handle the form fill/click/redirect-check.</p> <h3 id="summary-data-model-changes">Data model changes</h3> <p>New state-log entry: <code>menu_builder_blocked</code> in <code>state.jsonl</code>. New skill artifact template: <code>docs/migration/workflow/blocked.md</code>.</p> <h3 id="summary-internal-references">Internal references</h3> <ul> <li>Source markdown: <code>RESEARCH-2026-04-28/99-final/ISSUES/Sprint-2-Determinism/01-P0-6-menu-builder-post-auth-fails-64min-dead-time.md</code> (id: P0-6)</li> <li>Recommended verbatim text: <code>RESEARCH-2026-04-28/99-final/migrate-site-skill-recommendations.md</code> (<code>.claude/agents/menu-builder.md</code> SUCCESS REDIRECT DETECTION + RETRY LIMIT blocks)</li> <li>Pattern: <code>RESEARCH-2026-04-28/07-cross-cutting/patterns.md</code> &sect; B2 (Acquia WAF Blocks POST &mdash; full URL pattern table for success vs failure redirects)</li> <li>User feedback: <code>RESEARCH-2026-04-28/07-cross-cutting/user-feedback-corpus.md</code> &sect; Group 1 ("Why Are You Stopping?")</li> <li>Anti-pattern: <code>RESEARCH-2026-04-28/07-cross-cutting/session-anti-patterns.md</code> &sect; AP1 (Retry Storm &mdash; inverse: stops too early rather than retrying too much; same root cause of misdiagnosing the failure)</li> <li>Empirical probe (API-first alternative blocked): <code>RESEARCH-2026-04-28/99-final/SCOPE-PROBE-FINDINGS-2026-05-01.md</code> &sect; 6 ("Menu items &mdash; read works, write does NOT")</li> <li>Memory file: <code>feedback_acquia_post_auth_gotcha.md</code> ("Drupal menu-save success looks like redirect; retry on genuine Acquia WAF redirects.")</li> </ul> <h3 id="summary-open-questions">Open questions</h3> <ul> <li>The user expects "full browser automation, not a <code>blocked.md</code> fallback." Is the <code>blocked.md</code> + 1-retry cap acceptable as an interim fix while 2-02 (deterministic script) is being built?</li> <li>What is the path of the existing <code>.canvas-browser/</code> Chrome profile, and can it be seeded with exported cookies from an authenticated Chrome session without restarting the browser?</li> <li>In a recorded session, the agent eventually solved the menu POST by direct Bash + browser automation (not the menu-builder subagent). What were the exact commands? Those become the template for the deterministic script in 2-02.</li> </ul>